launchpad developmentA proof-of-concept implementation of an ACL system is available in lp:~bjornt/launchpad/privacy-spike. We're going to use that to implement ACLs for bugs. The reason we're doing this is to get something landed, so that we can test things using real data and use cases.
The first phase will consist of replacing the BugSubscription table with the BugTaskACL table when doing permission checking. This change won't be visible to the users, everything is done under the hood, keeping the existing UI and functionality. It will still be required to get subscribed to a private bug in order to see it.
These are the list of tasks that need to happen. Each task should be possible to implement and land in its own branch. They don't necessarily need to happen in the order below, but some tasks do depend on other tasks.
Add the BugTaskACL table - get the db patch and model class landed.
Add the IACL interface and adapter, etc. - add the general ACL infrastructure that is needed, like the IACL interface and base adapter, the ACLObjectType enum, __acl_class__ attribute, etc.
Populate BugTaskACL table and keep it up-to-date when subscribing/unsubcribing, and changing privacy, the ACLs for the bugtasks should be updated to reflect the subscriber list if the bug is private, or to be the public ACL if it's public. We will have to update the ACLs for all the bug tasks, since the subscription is per bug, not per bug task.
Use the BugTaskACL table instead of the BugSubscription table - to check whether the user has access to view the bug. Before doing this, testing should be performed on staging, to ensure that we don't have a performance regression.
Add BugTask.private and write a trigger to keep it up-to-date - to keep queries for public bugs fast, we need to have an attribute on the bugtask to indicate whether it's public or private (public is the common case and should be fast). We don't need to use the attribute yet, since we already check Bug.private.
Use BugTask.private instead of Bug.private in permission queries - we want security to be on the bugtask level, not on the bug level. We should update all places where we use Bug.private to use BugTask.private wehre possible. It might not be possible to update it everywhere, until we have the UI specification ready. For this reason, it might makes sense to not do any work at all on this task, before the UI is defined.
