I think we should stick with:
once a message is
in the user's mailbox, it stays there.
as we have agreed upon earlier. No need to delete sent messages.
A user should be able to read old messages, as he had the permissions
to do so when they were sent.
As Dick suggested this morning: "should we just prevent new messages
from the
now-forbidden pool going to the user." << this option has my vote.
I think a far more important is what happens if a pool is removed? And
if yes, what happens if someone later creates a pool with the same
name?
/Anne
On 1. okt. 2009, at 10.33, Vassil Dichev wrote:
Mail to a mailing list or IRC are not very private.
Not sure I see the use case here. The user has already read this
message. If the team lead didn't want the user to ever read the
message, why add the user to the pool in the first place?
Anyway, here's the design specifications document:
http://groups.google.com/group/esme-dev/files
On Thu, Oct 1, 2009 at 11:21 AM, Xuefeng Wu <[email protected]> wrote:
mail and IM is private but pool is public or group own.
If a team leader create a pool, does he want people who leave pool
could
read old message?
I do not think so.
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
