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 16:05:45 GMT
If the pool is deleted.We need not do anything for the messages and prevent
user send message into the pool.

That's all?

On Thu, Oct 1, 2009 at 11:27 PM, David Pollak <feeder.of.the.bears@gmail.com
> wrote:

> On Thu, Oct 1, 2009 at 2:05 AM, Anne Kathrine Petter√łe <
> akpetteroe@gmail.com
> > wrote:
>
> > 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 name?
> >
>
> If a pool is deleted, the messages in the users timeline stay, but it is as
> if all the users were deleted from the pool.
>
> Pools should not be name-dependent (sorry, I don't remember the current
> implementation).  They should have a GUID (think federation) so that the
> internal access to the pool is via GUID.  Thus, you can change the name of
> the pool.  You can delete the pool and create another with the same name.
>  You could conceivably (I don't know if this is a good idea from a
> user-perspective) create many pools with the same name.
>
>
> >
> > /Anne
> >
> >
> > 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:
> >>
> >> http://groups.google.com/group/esme-dev/files
> >>
> >>
> >> On Thu, Oct 1, 2009 at 11:21 AM, 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, 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 <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
> >>>
> >>>
> >
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>



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