launchpad-dev team mailing list archive

[Tim Penhey <tim@xxxxxxxxxx>]

Hi Bjorn (and other interested parties),

I have a number of concerns, most of them around the fundamentals of how it 
will all be implemented, efficiency of queries, how this will work with 
collections and so on.

Firstly though, I was a little confused by one of the first examples, and it 
certainly seemed counter-intuitive.

> If you need to limit who can view the project, you can grant permissions
> to specific people or teams::
> 
>     >>> project_acl.grant(VIEW, bob)
> 
>     >>> project_acl.has(VIEW, alice)
>     False
>     >>> project_acl.has(VIEW, bob)
>     True
> 
>     >>> project_acl.grant(VIEW, alice)
>     >>> project_acl.has(VIEW, alice)
>     True

Before this we had shown that everyone had view access to the project, 
including alice and bob.  Granting view permission for bob should not effect 
alice.  In order for alice to not see it, we should have either revoked 
alice's view permission, or revoked view for everyone.

Which brings me to another question.

What happens if we have:
  view for everyone
  view revoked for alice

Can alice see it because she is one of everyone?  How is exclusion going to 
work.

Is it that if the user gets visibility through any team, they get view 
permission?

What permissions are we talking about here?  Just VIEW, and EDIT, or are we 
going for CRUD (create, read, update, delete)?  What about admin and other 
special permissions?

Is this going to be a replacement for our security adapters or an enhancement 
to it?  If it is an enhancement, do we know how yet?

It was mentioned that subsystems (or applications) of Launchpad can have 
different ACLs, but no example is given.  I'm curious as to how that'd be 
implemented too.

Also, the example shows privacy on a bug task.  How does this relate to the 
but itself?  What if a bug has multiple tasks, but some are private?

I'm sure I'll end up with more questions later.

Tim