[
https://jira.duraspace.org/browse/DS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Donohue updated DS-457:
---------------------------
Status: Volunteer Needed (was: Received)
> 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
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
