It well be easy ? If we do not whether user read or unread, just leave the message in his/her mailbox and could read whenever.
And we never sent message to a user who leave the pool? On Thu, Oct 1, 2009 at 6:54 PM, Richard Hirsch <[email protected]>wrote: > The team leader would have no idea whether the user had read the > message or not. The assumption is that the user has read it. The user > was also part of the pool when the message was created - thus, at this > particular point in time, he actually did have the right to view the > message. > > > > On Thu, Oct 1, 2009 at 12:39 PM, Xuefeng Wu <[email protected]> wrote: > > mail and IM is private but pool is public or group own. > > If a team leader create a pool and does he want that some people who > leave > > team could red old message? > > > > 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 > > > -- Global R&D Center,Shanghai China,Carestream Health, Inc. Tel:(86-21)3852 6101
