incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <feeder.of.the.be...@gmail.com>
Subject Re: Deleting user from access pool
Date Thu, 01 Oct 2009 16:07:46 GMT
On Thu, Oct 1, 2009 at 9:05 AM, Xuefeng Wu <benewu@gmail.com> wrote:

> If the pool is deleted.We need not do anything for the messages and prevent
> user send message into the pool.
>
> That's all?
>

I think so.


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



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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message