I tried, I also should modify Privilege.find*ablePools after set Privilege invalidate.
On Thu, Oct 1, 2009 at 7:43 PM, Xuefeng Wu <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected] >> >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 <[email protected]> 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 <[email protected]> >> >> 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 <[email protected]> >> 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 < >> >> [email protected] >> >> >> >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 <[email protected]> >> 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 < >> [email protected] >> >> > >> >> >> >> 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
