launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02837
Re: RFC Changing permissions to allow contributors to set upstream information
On March 2, 2010, Curtis Hovey wrote:
> Implementation notes
> ....................
>
> I think the proposed permission rules imply the return of the despicable
> EditPersonLocation-style permission checker...
>
> class EditProductSomething(EditByOwnersOrAdmins):
> permission = 'launchpad.EditSomething'
> usedfor = IProduct
>
> def checkAuthenticated(self, user):
> """Anybody can edit something if it is not set."""
> something = self.obj.something
> if something is None:
> return True
> else:
> return super(EditProductSomething,
> self).checkAuthenticated(user)
>
> ...and the setup of some unique views to isolate this kind of change.
>
> Since we are striving to remove the exceptional permission names, this
> whole category of needs a name and story that is easy to test when we want
> to reuse the permission name. We have a few cases of launchpad.append, but
> I do not think that is this case. I also discount launchpad.moderate. This
> looks like a launchpad.Propose, or launchpad.Suggest.
I suggest we use launchpad.Edit. For these attributes, but allow setting them
from two places, the object directly where the current checker is used
(owner/admin only). And a CommunityEditableMetadata objects which would use
the more fancy checkers.
>
> I have some reservation about this whole proposal--users cannot fix their
> mistakes. This will lead to requests to other users to fix the data, and
> lead to bug reports just like the reports to edit/delete comments.
We might want to store the last user who set the attribute and make the
checker give permission to that user for that attribute on a more permanent
basis.
We probably also want some audit logs of attribuets set by community members.
--
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
References