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 13:22:54 GMT
I tried, I also should modify Privilege.find*ablePools after set Privilege
invalidate.

On Thu, Oct 1, 2009 at 7:43 PM, Xuefeng Wu <benewu@gmail.com> wrote:

> So we only need to add a new attribute validate at Privilege and modify
> Privilege.hasPermission.
>
>   def hasPermission(userId: Long, poolId: Long, permission:
> Permission.Value) = Privilege.find(
>     By(user, userId),
>     By(pool, poolId),
>     *By(validate, true)*
>   ).map(_.permission.is >= permission).getOrElse(false)
>
> It's done at server-side?
>
> On Thu, Oct 1, 2009 at 7:30 PM, 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
>> >
>>
>
>
>
> --
> 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