launchpad-dev team mailing list archive

[Henning Eggers <henning.eggers@xxxxxxxxxxxxx>]

Am 20.12.2009 02:51, Jonathan Lange schrieb:
> The other thing is that the function's external API is pre-supposing
> certain policy decisions. It's much better to name the function after
> what you actually _want_ rather than the mechanism for figuring it
> out.
> 
> e.g. can_translate() rather than user_is_admin_or_rosetta_expert()
> 
> An example from the package branches extravaganza: rather than
> checking Branch.product is None, we now check
> Branch.supportsMergeProposals() (or something like that).

I like that very much and have done that myself before. I think I can
take these rules from the discussion:

1. Do not use the checker classes from security.py anywhere else, i.e.
do not call "SomeThing.checkAuthenticated(user)" from model code.

2. Permission checks specific to a model class should be placed into
that class as "canDoSomething(user)" methods and called from the
checkers in security.py on self.obj. I think that a lot of the checks
fall into this category and the checking code could be moved into the model.

3. The functions I put into permission_helpers.py are either too
specific or too trivial. I see that now and will do away with it. I
guess what I am mostly concerned about is the ILaunchpadCelebrities
noise. I would prefer to be able to simply check a "user.is_admin" property.

Adi, does that help you with the original discussion we had?

Henning