incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Deleting user from access pool
Date Sun, 11 Oct 2009 04:02:54 GMT
I think the permission history is a very important. I know based on my
work in compialance-related work that this information is critical.
Maybe, we can create a separate log-file where this information is
retained for record-keeping purposes.

@Vassil - the patch is attached to the Jira item
(https://issues.apache.org/jira/browse/ESME-87)

D.

On Sun, Oct 11, 2009 at 2:11 AM, Xuefeng Wu <benewu@gmail.com> wrote:
> @Vassil, thank you for  your reply. Great analysis!
>
> On Sun, Oct 11, 2009 at 4:26 AM, Vassil Dichev <vdichev@apache.org> wrote:
>
>> > Yes, I have some questions.
>> > I already have a patch to delete the user from pool by delete Privilege.
>>
>> Xuefeng,
>>
>> Thanks for all your work! I'm sorry for the delayed reply, I wasn't
>> online for some time.
>>
>> > I have some questions when run your user case at .
>> > 1. After delete user from pool, he/she could not see the pool's messages
>> > which already in mailbox.
>> > And the some he/she can not find any message from the pool from *Streams*
>>
>> Yes, you're correct that this behavior is not very consistent.
>> Currently what you see in the mailbox will sometimes show messages not
>> seen via other means (streams, going to a user's personal timeline,
>> search, etc.), and vice versa. Whether a message goes in the Mailbox
>> is decided on what pools a user is at the time the message has been
>> received, and then the message is there forever. What's in streams is
>> filtered by what pools a user is currently in. There is a single place
>> where I control which messages a user can see, so we can change that
>> if there's the wish to do so.
>>
>> For our purposes, let's discuss only the Mailbox (mail-box? should we
>> rename this class?) That's what the user will see on his timeline.
>>
>> > 2. If  user B follow user A and delete user B from a pool, and A write
>> > message in the pool.
>> > B will receive* the messages *from A which is writen in the pool.
>> >
>> > I think that the cache is UserActor:
>> > private var pools: Set[Long] = Set()
>> >
>> > I need to add many method to refresh it for every following, is there any
>> > easy way?
>> >
>> > I attach the patch although it did not work perfect.
>>
>> I see that you're already getting deep in the access pools
>> implementation. Yes, the pools variable is the in-memory pool set of
>> the corresponding user. This is why anytime I add a pool, I send a
>> message (AllowUserInPool) to Distributor, and it sends a message to
>> UserActor in turn (AllowPool) to refresh this variable. We need to add
>> handling for DisallowPool or something similar- it should be very
>> similar to what's done for AllowPool.
>>
>> As for method followingIdsForUserId, there is already a variable in
>> UserActor, called followers (similar to pools above), doesn't it fit
>> the purpose? Note that it's better to send messages to the actors than
>> use methods, because messages are synchronized on an internal message
>> queue. I can tell you more when I see some code.
>>
>> Regarding history of permissions: very good idea. This is also one
>> more reason to use a discrete permission type- NoPermission, instead
>> of another field- isValid. This way we can just create a new
>> permission type in the DB with a timestamp and it would be much easier
>> to track what has changed and when. So if a user had read permission,
>> then write permission and then is deleted, the history would show
>> Read, Write and NoPermission in a chronological sequence. Does this
>> make sense?
>>
>> Thanks again for the progress, please keep it up and don't hesitate to
>> tell us where the pain points are!
>>
>> Vassil
>>
>
>
>
> --
> Global R&D Center,Shanghai China,Carestream Health, Inc.
> Tel:(86-21)3852 6101
>

Mime
View raw message