[
https://jira.duraspace.org/browse/DS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Taylor updated DS-457:
----------------------------
Fix Version/s: (was: 1.8.0)
post-1.8.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: post-1.8.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:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
