If the pool is deleted.We need not do anything for the messages and prevent user send message into the pool.
That's all? On Thu, Oct 1, 2009 at 11:27 PM, David Pollak <[email protected] > wrote: > On Thu, Oct 1, 2009 at 2:05 AM, Anne Kathrine Petterøe < > [email protected] > > wrote: > > > I think we should stick with: > > > >> once a message is > >> in the user's mailbox, it stays there. > >> > > as we have agreed upon earlier. No need to delete sent messages. > > A user should be able to read old messages, as he had the permissions to > do > > so when they were sent. > > As Dick suggested this morning: "should we just prevent new messages from > > the > > now-forbidden pool going to the user." << this option has my vote. > > > > I think a far more important is what happens if a pool is removed? And if > > yes, what happens if someone later creates a pool with the same name? > > > > If a pool is deleted, the messages in the users timeline stay, but it is as > if all the users were deleted from the pool. > > Pools should not be name-dependent (sorry, I don't remember the current > implementation). They should have a GUID (think federation) so that the > internal access to the pool is via GUID. Thus, you can change the name of > the pool. You can delete the pool and create another with the same name. > You could conceivably (I don't know if this is a good idea from a > user-perspective) create many pools with the same name. > > > > > > /Anne > > > > > > On 1. okt. 2009, at 10.33, Vassil Dichev wrote: > > > > Mail to a mailing list or IRC are not very private. > >> > >> Not sure I see the use case here. The user has already read this > >> message. If the team lead didn't want the user to ever read the > >> message, why add the user to the pool in the first place? > >> > >> Anyway, here's the design specifications document: > >> > >> http://groups.google.com/group/esme-dev/files > >> > >> > >> On Thu, Oct 1, 2009 at 11:21 AM, Xuefeng Wu <[email protected]> wrote: > >> > >>> mail and IM is private but pool is public or group own. > >>> If a team leader create a pool, does he want people who leave pool > could > >>> read old message? > >>> I do not think so. > >>> > >>> On Thu, Oct 1, 2009 at 3:58 PM, Vassil Dichev <[email protected]> > >>> wrote: > >>> > >>> There are counterexamples- when you send out an email, it's in the > >>>> inbox of the people you have sent it to and you cannot delete it. When > >>>> you send a message in an instant messaging client, you cannot get it > >>>> back. In the context of JIRA, the item can still change after > >>>> permission is denied to you, while the message cannot be reedited in > >>>> ESME. > >>>> > >>>> I'm with Dick here. The performance problem is that the stream of > >>>> messages is updated in near real-time and any deleted messages will > >>>> cause a cascade of changes across the inboxes of all users who have > >>>> linked this message. > >>>> > >>>> I think we discussed deleting messages before, not in the context of > >>>> this pool, and David strongly favored the opinion that messages should > >>>> be immutable- once they're sent, that's it. Deleting messages also > >>>> poses security/consistency issues with possible federation scenarios, > >>>> which David intended to implement. > >>>> > >>>> There are many many other inconsistency issues which could arise if we > >>>> start deleting messages. Take for example, resending. If a resent > >>>> message is deleted, do you delete it from the inboxes of all your > >>>> followers? And if it's a popular resent message, do you delete it from > >>>> the stats actor? Do you reevaluate all the statistics for resent > >>>> messages then? What if the message contains tags, do you reevaluate > >>>> the tag cloud? What if it contains links, which are in the popular > >>>> links stats? What if the message is part of a conversation, do you > >>>> delete the whole conversation? > >>>> > >>>> So in the end, the immutability of messages and timelines is already > >>>> deeply ingrained in the ESME architecture and is not subject to > >>>> change- even if we decide that it's wise to do so, which I think it's > >>>> not. It's far from a trivial change. > >>>> > >>>> Vassil > >>>> > >>>> > >>>> On Thu, Oct 1, 2009 at 10:37 AM, Xuefeng Wu <[email protected]> wrote: > >>>> > >>>>> If user could not see any message from a pool which he/she leave, > even > >>>>> his/her message, What will happen? > >>>>> In a company, If some one leave a team/project/department, he/she may > >>>>> be > >>>>> could not read any document even he/she write. > >>>>> > >>>>> The messages are also some resource for a team/project/department, I > >>>>> > >>>> think > >>>> > >>>>> it's fine that do not allow users can not read any messages in the > >>>>> pool. > >>>>> > >>>>> Think about jira, if you create a issue(task, defects) and the > >>>>> permission > >>>>> said only team members. > >>>>> And if you leave the team, you can not read the issue anymore. > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Oct 1, 2009 at 12:51 PM, Richard Hirsch < > [email protected] > >>>>> wrote: > >>>>> > >>>>> Regarding the first part (deleting users from a pool) - here are my > >>>>>> > >>>>> ideas > >>>> > >>>>> * We have no idea whether he has viewed the messages or not. > >>>>>> * Of course, he should be able to continue see his own messages even > >>>>>> if they were sent to a pool to which he no longer belongs. > >>>>>> * The user's messages remain in the pool whether or not the user is > in > >>>>>> > >>>>> the > >>>> > >>>>> pool. > >>>>>> * Since the user can no longer view the pool, he can only view his > own > >>>>>> messages but not those of other users. > >>>>>> * Question: Should we delete all old messages from the pool to which > >>>>>> the user was a member or should we just prevent new messages from > the > >>>>>> now-forbidden pool going to the user. I prefer the second choice. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> To the second point regarding the deletion of pools. I think this > >>>>>> needs more thought. We can't / shouldn't delete messages from closed > >>>>>> pools. This would be a performance and programming nightmare. > >>>>>> > >>>>>> D. > >>>>>> > >>>>>> On Thu, Oct 1, 2009 at 5:23 AM, Xuefeng Wu <[email protected]> > wrote: > >>>>>> > >>>>>>> There're two features:1. delete users from pool; > >>>>>>> 2. delete pool. > >>>>>>> > >>>>>>> There're some argue and my opinion: > >>>>>>> *when delete users from pool.* > >>>>>>> We could withdraw all messages from the user, whatever read or > >>>>>>> unread. > >>>>>>> > >>>>>>> *when delete pool. ESME-68* > >>>>>>> withdraw all messages > >>>>>>> can create new pool which have the same name as deleted > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Sep 30, 2009 at 3:59 PM, Vassil Dichev <[email protected] > > > >>>>>>> > >>>>>> wrote: > >>>>>> > >>>>>>> > >>>>>>> Should we allow for a user to be deleted from an access pool? > >>>>>>>>> > >>>>>>>>> If yes what happens? Does he no longer have access to the > messages > >>>>>>>>> > >>>>>>>> in > >>>> > >>>>> the pool - irregardless of whether he wrote them or not? > >>>>>>>>> > >>>>>>>> > >>>>>>>> It should be possible to delete a user, yes. I think it has been > >>>>>>>> discussed or specified in the requirements pdf that once a message > >>>>>>>> is > >>>>>>>> in the user's mailbox, it stays there, so that's how it works now. > >>>>>>>> At > >>>>>>>> any rate, deleting a message from the mailbox, which the user may > >>>>>>>> > >>>>>>> have > >>>> > >>>>> already seen doesn't offer any more security. A user also doesn't see > >>>>>>>> messages in his/her mailbox, which were sent before he was added > to > >>>>>>>> the pool. > >>>>>>>> > >>>>>>>> The interesting part is what happens if a pool has been removed > and > >>>>>>>> whether it should be possible at all. This could pose a security > >>>>>>>> problem if an impostor creates a pool with the same name (similar > to > >>>>>>>> what might happen with a deleted user account) > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Global R&D Center,Shanghai China,Carestream Health, Inc. > >>>>>>> Tel:(86-21)3852 6101 > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Global R&D Center,Shanghai China,Carestream Health, Inc. > >>>>> Tel:(86-21)3852 6101 > >>>>> > >>>>> > >>>> > >>> > >>> > >>> -- > >>> Global R&D Center,Shanghai China,Carestream Health, Inc. > >>> Tel:(86-21)3852 6101 > >>> > >>> > > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > -- Global R&D Center,Shanghai China,Carestream Health, Inc. Tel:(86-21)3852 6101
