> 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
