Thanks for the comments Johan. I'll look into improving what I've done using the find_project method as you suggest.
I'll do some thinking on the invitation way of getting contributor's on board. I can see cases where either the "invitation" method or the "passkey" method would be preferable. For example, I am thinking that the passkey method would be preferable in a teaching setting (looking to implement this for my students in one of my uni classes): the group leader would let the group's members know of their project's pass key, and the members would sign up without any further effort from the leader/owner. In both cases though, a proper membership model would help a lot. And I can't see why both methods could not use the same model. Regards, Peter On Jan 15, 7:36 pm, "Johan Sørensen" <[email protected]> wrote: > Hi, > > On Thu, Jan 15, 2009 at 1:04 AM, Peter <[email protected]> wrote: > > > I have written a way for projects to be made private or public > > individually. A private project cannot be accessed by anyone except > > the owner and any authorized contributors (if any). > > Nice. There's been a few requests for this, so it's quite timely. > > > This is how contributor authorization works: > > > * The owner specifies a passkey in a field in the Project Settings > > page. > > * A user that wants to become a contributor gets this passkey from the > > project owner (they can email for it, call, etc.) > > * Once the aspiring contributor has the passkey, he goes to the > > project's home page and types it in the box (the box will not show up > > if the user is not logged on). > > * If the passkey is correct, the user gets instant access to the > > project. > > > I would be very interested in your comments. > > I'm thinking we should do a proper project memberships model, with > roles attached. That way, adding a member to a project is a matter of > inviting them; type in their email address, wait for them to click the > confirm link. > > Rather than doing the "is this a private project?" checking in the > views and helpers like you're doing a lot of place, it's much easier > (both in implementation and maintenance) to check it in a before > filter. There's a find_project method in the application controller > that is used throughout (or should be at least, if it's not I've been > doing it wrong). After it has found a given project would be a good > time to check for its privateness, and either redirect back with a > flash[:error] or render a page and stop the filter chain. > That way we'll have less places where the authorization is done and > that makes maintaining it easier in the long run. > > > > > Peter > > Cheers, > JS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Gitorious" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/gitorious?hl=en -~----------~----~----~----~------~----~------~--~---
