launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

On 13/04/12 06:42, Robert Collins wrote:
> So when you say 'set it back to some and the originally visible
> artifacts will be visible again', do you mean 'you would reconstruct
> grants based on existing subscriptions' ? Thats dangerous, because of
> shuffling of transitive memberships.
> 
> Its also a more complex UI.
> 
> Being able to programmatically undo mistakes is a laudable UI goal but
> can create -substantial- complexity.
> 
>>From a data integrity perspective, we must not have two different
> sorts of data arguing: if there is a subscription, the user must have
> a grant. Removing a grant must remove any subscriptions (not
> necessarily atomically - a background job is fine).
> 


The way it is now is an interim state while we finalise the work to
separate subscriptions from access/visibility. What we plan to do is
delete the access grants and fire off a celery job to delete the
associated subscriptions. If the user is given access to an artifact
thereafter, they will need to resubscribe to the artifact if they wish
to receive email notifications about changes to the artifact. The idea
is that users will ultimately need to have relatively few direct
artifact subscriptions so correcting mistakes won't be too onerous.

The alternative to deleting subscriptions is to make the subscriptions
subsystem aware of access policies. So the subscribers portlet and email
recipients list would be constructed by doing the intersection of
subscribers and those with access. This is more complex and also can
result in obsolete subscriptions being left around slowing everything
down for no good reason.