On 5/9/07, Priscilla Chung <[EMAIL PROTECTED]> wrote:
*Proposal B* Keep the current 'Remove' button in the detail view, but when the user selects 'Remove' it is not a hard delete off the server. Effectively the item would be hidden from view in the collection, but remain on the server so in the other shared collections where the item might have been copied would not be deleted.
this is how remove works in 0.6.1. when an item is "removed", it is disassociated from that collection, but it remains in any any other collections it might have been in. if the item was only in the one collection then it is completely deleted. in all cases, when an item is removed from a collection (regardless of whether it is ultimately deleted from storage or not), a tombstone is created that allows desktops to sync the collection and see that the item was removed.
*Proposal C* When the user selects the 'Remove' button and the items belongs to other collections, a dialog would appear and inform the user and give them the option: 'The item you are about to delete are shared in 3 other collections. Would you like to remove it from this collection or delete it from all collections. [Delete] [Remove]
the server already supports this in 0.7, so all of the effort would be on the web end. note that if an item has been copied from user a's collection into user b's collection, the server will not allow user a to remove the item from user b's collection. the server will only allow user a to remove the item from his own collections. is this good enough? a real acl system in the server would fix this problem. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
