Ticket #506 (new enhancement)

Opened 15 years ago

Last modified 13 years ago

protect stack elements

Reported by: atchertchian Owned by: janguenot
Priority: P2 Milestone: CPS 3.5.7
Component: CPSWorkflow Version: TRUNK
Severity: normal Keywords: stacks

Description (last modified by atchertchian) (diff)

protect stack elements

Some use cases require that stack elements should not be visible/editable according to the current user rights and according to the stack (stack structure/configuration/level/whatever), even if he can manage the stack.

For instance, in Messager, we use hierarchical stacks were Cabinet users cannot see Direction users that are not immediately(1) surrendered by another Cabinet user/group.

Plus this could prevent people from deleting themselves from the stack if nobody else will be able to manage the stack afterwards.

(1) Immediately means: same level, or level + 1 or level -1.

Change History

comment:1 Changed 15 years ago by atchertchian

Of course this has to deal with the fact that in some cases, stacks elements will be edited even if the user's not supposed to be able to do it.

For instance (hierarchical stack) :

  • user1 is at current level, 0, and manages the stack
  • user2 is at level 1 and can be edited by user1
  • user3 is at level 2 and cannot be edited bu user1

If user1 inserts user4 between levels 0 and 1, user2 will go to level 2 and user3 will have to go to level 3 even if user1 is not supposed to move him. Got it? ;)

comment:2 Changed 14 years ago by atchertchian

More genrally, maybe it could be useful to handle a "private" _getStackContent, without retrictions on rights on stack elements, because the stack management needs it, and a "public" getStackContent when someones acceses the stack.

comment:3 Changed 14 years ago by janguenot

  • Version changed from CPS 3.3 branch to TRUNK

Are the guards enough nowadays for this Anahide ?

comment:4 Changed 14 years ago by atchertchian

  • Description modified (diff)
  • Severity changed from normal to enhancement

Which one ? :)

Probably ok even if I didn't tried it yet, and available namespace in conditions seems enough to get the described behaviours. But I think separation of private/public API is not done. Let's change it to enhancement unless you'd like to close it for some yagni reason :)

comment:5 Changed 14 years ago by janguenot

  • Milestone changed from unspecified to CPS 3.5.0

comment:6 Changed 13 years ago by atchertchian

private/public api separation is done, but stack element edit guard is not checked in edit actions.

Note: See TracTickets for help on using tickets.