incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Deleting user from access pool
Date Thu, 01 Oct 2009 13:48:03 GMT
I agree with this (for what it's worth). From an end user perspective
I think of my view of the historic timeline as immutable. I would be
very confused if a message or whole conversation disappeared from that
timeline and orphaned related messages and conversations.

I think leaving old messages in the user timeline and not adding new
messages from the pool is the right behavior.

That said, what if a user has a significant role-change within a
company? For example, the user goes from being an employee to being a
supplier (and suppliers use the same ESME instance). In this case the
company would probably not want the user to be able to access old
messages on the server. But in this case it is really a matter of the
company not wanting the user to be able to access the old
timeline/account at all. The company would create an entirely new
account for the user.

In that case, I think the use-case is covered as well, by the user
management side of the house.

Ethan

On Thu, Oct 1, 2009 at 7:30 AM, Richard Hirsch <hirsch.dick@gmail.com> wrote:
> Yes. That is easier. We don't have to worry about existing messages in
> the message queues and we just have to prevent future messages from
> the now probited pool from going to the user.
>
> On Thu, Oct 1, 2009 at 1:25 PM, Xuefeng Wu <benewu@gmail.com> wrote:
>> 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 <hirsch.dick@gmail.com>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 <benewu@gmail.com> 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 <vdichev@apache.org>
>>> 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 <benewu@gmail.com>
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 <
>>> hirsch.dick@gmail.com
>>> >> >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 <benewu@gmail.com>
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 <vdichev@apache.org
>>> >
>>> >> >> 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
>>
>

Mime
View raw message