esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
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


On Sun, Oct 11, 2009 at 2:11 AM, Xuefeng Wu <> wrote:
> @Vassil, thank you for  your reply. Great analysis!
> On Sun, Oct 11, 2009 at 4:26 AM, Vassil Dichev <> 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

View raw message