Thanks bcm, my reply inline:
On May 9, 2007, at 12:59 PM, Brian Moseley wrote:
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.
Great so it looks like there's no work to be done for preview.
*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.
I'll change the summary in the current bug to add this proposal,
target and revisit for future.
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?
Yes.
a real acl system in the server would fix this problem.
Heh. ;)
-Priscilla
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
