[
https://jira.duraspace.org/browse/DS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Masár updated DS-457:
--------------------------
Fix Version/s: (was: 3.0)
4.0
> When a Workflow group is updated, existing Tasks still have the same set of
> Epersons authorized to take task.
> -------------------------------------------------------------------------------------------------------------
>
> Key: DS-457
> URL: https://jira.duraspace.org/browse/DS-457
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.2, 1.6.0
> Reporter: Larry Stone
> Priority: Major
> Fix For: 4.0
>
>
> 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
