[
http://jira.dspace.org/jira/browse/DS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-457:
---------------------------
Affects Version/s: 1.6.0
Fix Version/s: 1.n
Issue Type: Improvement (was: Bug)
Discussion from Dev Meeting on Feb 10, 2010. I've changed issue's type to an
Improvement request:
[15:34] <tdonohue> http://jira.dspace.org/jira/browse/DS-457 "When a Workflow
group is updated, existing Tasks still have the same set of Epersons authorized
to take task."
...
[15:35] <richardrodgers> 457 looks like a feature request more than a bug
...
[15:36] <mhwood> The underlying problem is that access is granted by value, not
by reference. IIRC there are a number of places where people complain that old
permissions have "stuck" to things when they should track changes in roles and
permissions.
[15:36] <tdonohue> yep. I agree with both mhwood and richardrodgers on DS-457 -
looks like a new feature request, as a lot of things behave this way
[15:37] <mhwood> It's not a bug; it's a misfeature. :-)
[15:37] <tdonohue> good point...where is that setting in Jira (kidding) :)
...
[15:37] <mhwood> Seriously, it was designed one way, and it works properly that
way, but people seem to want it to work another way. "Improvement request"
> When a Workflow group is updated, existing Tasks still have the same set of
> Epersons authorized to take task.
> -------------------------------------------------------------------------------------------------------------
>
> Key: DS-457
> URL: http://jira.dspace.org/jira/browse/DS-457
> Project: DSpace 1.x
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.2, 1.6.0
> Reporter: Larry Stone
> Fix For: 1.n
>
>
> This scenario illustrates the bug:
> 1. User Alice submits an item "Bar" to Collection Foo, and it enters workflow.
> 2. At some later time, user Bob is added to Foo's "workflow step 1" group.
> However, Bob is surprised not to see item Bar on his task list! The reason:
> At the time Bar entered workflow, he wasn't in the relevant group, and
> WorkflowManager computes and caches the list of authorized task takers at the
> time a WorkflowItem enters the step.
> If your repository has Items that tend to linger in the workflow for a long
> time, and workflow approver groups get updated at a somewhat greater
> frequency, you will probably notice this bug. It may be rarely enough
> noticed that it hasn't drawn much attention, however.
> There is a sound reason for this situation -- it's a necessary optimization
> given the fact that groups are defined recursively so a single SQL query
> cannot report whether user Bob is actually a member of the given workflow
> item's group. With a cached flat list of e-people, the query is possible and
> efficient.
> I can think of a few different solutions, however, that would work around
> this deficiency:
> a. Maintain cached flat expansion of each Group in the DB. This would have
> to be recomputed every time a group is changed, but that is a rare event.
> The TasklistItem table would be unnecessary since the flat-group table would
> take its place.
> b. Recompute the TasklistItem table periodically, perhaps as a daily cron
> job, so at least group updates would eventually catch up.
> c. Implement option (a) but recompute the flat-group table periodically or
> when it is marked "dirty" by a change to Group membership.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
