Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of benewu@gmail.com designates
 209.85.211.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ppK6tWnVE77DaS5Vc9kJG7kHKJaWXzrOIiF+0G8iq083DMS1x1nJydESNGvm+TA2SS
         lRtSnmgZGu4+0yxmC6OP6C4z3KEf3duV7cUa6tW/z4bDx40wAqvQtGH9A9qEc69fH10g
         zpGmLWk/YSCHDv67tLMLQkLTBEWEemjkEftp0=
MIME-Version: 1.0
In-Reply-To: <fa2d9f450909302151v31cfcf1dn53674dd4b00d80bf@mail.gmail.com>
References: <fa2d9f450909300000k1dfb07eerfadd4ed15f122ad2@mail.gmail.com>
	 <c7fc82820909300059w72306b7es36cee99464f1debd@mail.gmail.com>
	 <4db64d890909302023n56114990s2e6197554e63a0ed@mail.gmail.com>
	 <fa2d9f450909302151v31cfcf1dn53674dd4b00d80bf@mail.gmail.com>
Date: Thu, 1 Oct 2009 15:37:43 +0800
Message-ID: <4db64d890910010037o15c7d7du785deb893852e15c@mail.gmail.com>
Subject: Re: Deleting user from access pool
From: Xuefeng Wu <benewu@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001636ed6b5d0f81700474dab903

--001636ed6b5d0f81700474dab903
Content-Type: text/plain; charset=ISO-8859-1

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

--001636ed6b5d0f81700474dab903--