esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petter√łe <>
Subject Re: Deleting user from access pool
Date Thu, 01 Oct 2009 09:05:29 GMT
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  


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:
> On Thu, Oct 1, 2009 at 11:21 AM, Xuefeng Wu <> 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 <>  
>> 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 <>  
>>> 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 <
>>>> 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 <> 

>>>>> 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 <

>>>>>> >
>>>>> 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

View raw message