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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
