incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xuefeng Wu <ben...@gmail.com>
Subject Re: Deleting user from access pool
Date Thu, 01 Oct 2009 11:25:12 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message