incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xuefeng Wu <ben...@gmail.com>
Subject Re: Deleting user from access pool
Date Thu, 01 Oct 2009 17:15:03 GMT
Thank you![?]

On Fri, Oct 2, 2009 at 1:11 AM, David Pollak
<feeder.of.the.bears@gmail.com>wrote:

> On Thu, Oct 1, 2009 at 9:49 AM, Xuefeng Wu <benewu@gmail.com> wrote:
>
> > I have a question about HTML element id.Where I write the element's id
> > attribute value? in code or Html?
> >
> > For example, I want add a feature to edit the pool's name.
> >
> > I have these snippet code:
> >
> > > def reDraw(*id*: String, content: NodeSeq) = SetHtml(id, content)
> >
> >     def poolName(ap: AccessPool): NodeSeq =
> > > swappable(<span>{ap.getName}</span> ,
> >
> >  <span>{ajaxText(ap.getName,
> >
> > v => {ap.setName(v); ap.save; reDraw("*pool_name_id*",
> > > <span>{ap.getName}</span>)})}
> >
> >  </span>)
> >
> >
> > As you see, I need the html element id value and reDraw .
> > In my opinion, the html attribute* id *is about business model and
> logical,
> > I should write the value at server side.
> >
> > But if I write these:
> >
> > >     def poolName(ap: AccessPool): NodeSeq =
> > > swappable(<span>{ap.getName}</span>  *% ("id" -> "pool_name_id"),*
> >
> >  <span>{ajaxText(ap.getName,
> >
> > v => {ap.setName(v); ap.save; reDraw("pool_name_id",
> > > <span>{ap.getName}</span>)})}
> >
> >  </span>)
> >
>
> swappable(<span id="pool_name_id">{ap.getName}</span>, ...)
>
> And then:
>
> reDraw("pool_name_id", Text(ap.getName))
>
> SetHtml puts stuff inside the element with the given id.  You're not
> over-writing the span.
>
>
> >
> >
> > Something will be wrong when user want to edit again without refresh the
> > page.
> >
> > *Is there any suggestion?*
> >
> >
> > On Fri, Oct 2, 2009 at 12:07 AM, David Pollak <
> > feeder.of.the.bears@gmail.com
> > > wrote:
> >
> > > On Thu, Oct 1, 2009 at 9:05 AM, Xuefeng Wu <benewu@gmail.com> wrote:
> > >
> > > > If the pool is deleted.We need not do anything for the messages and
> > > prevent
> > > > user send message into the pool.
> > > >
> > > > That's all?
> > > >
> > >
> > > I think so.
> > >
> > >
> > > >
> > > > On Thu, Oct 1, 2009 at 11:27 PM, David Pollak <
> > > > feeder.of.the.bears@gmail.com
> > > > > wrote:
> > > >
> > > > > On Thu, Oct 1, 2009 at 2:05 AM, Anne Kathrine Petter√łe <
> > > > > akpetteroe@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > 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?
> > > > > >
> > > > >
> > > > > If a pool is deleted, the messages in the users timeline stay, but
> it
> > > is
> > > > as
> > > > > if all the users were deleted from the pool.
> > > > >
> > > > > Pools should not be name-dependent (sorry, I don't remember the
> > current
> > > > > implementation).  They should have a GUID (think federation) so
> that
> > > the
> > > > > internal access to the pool is via GUID.  Thus, you can change the
> > name
> > > > of
> > > > > the pool.  You can delete the pool and create another with the same
> > > name.
> > > > >  You could conceivably (I don't know if this is a good idea from
a
> > > > > user-perspective) create many pools 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 <benewu@gmail.com>
> > > 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 <
> > vdichev@apache.org>
> > > > > >>> 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 <benewu@gmail.com
> >
> > > > 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
<
> > > > > hirsch.dick@gmail.com
> > > > > >>>>> 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 <
> benewu@gmail.com>
> > > > > 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 <
> > > > vdichev@apache.org
> > > > > >
> > > > > >>>>>>>
> > > > > >>>>>> 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
> > > > > >>>
> > > > > >>>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lift, the simply functional web framework http://liftweb.net
> > > > > Beginning Scala http://www.apress.com/book/view/1430219890
> > > > > Follow me: http://twitter.com/dpp
> > > > > Surf the harmonics
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Global R&D Center,Shanghai China,Carestream Health, Inc.
> > > > Tel:(86-21)3852 6101
> > > >
> > >
> > >
> > >
> > > --
> > > Lift, the simply functional web framework http://liftweb.net
> > > Beginning Scala http://www.apress.com/book/view/1430219890
> > > Follow me: http://twitter.com/dpp
> > > Surf the harmonics
> > >
> >
> >
> >
> > --
> > Global R&D Center,Shanghai China,Carestream Health, Inc.
> > Tel:(86-21)3852 6101
> >
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>



-- 
Global R&D Center,Shanghai China,Carestream Health, Inc.
Tel:(86-21)3852 6101

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message