[DuraSpace JIRA] (DS-2920) AuthorizeException on "take task" during workflow process

4 views
Skip to first unread message

Ivan Masár (DuraSpace JIRA)

unread,
Nov 25, 2015, 12:24:01 PM11/25/15
to dspace-...@googlegroups.com
Franziska Ackermann created an issue
 
DSpace / Bug DS-2920
AuthorizeException on "take task" during workflow process
Issue Type: Bug Bug
Affects Versions: 5.4
Assignee: Unassigned
Attachments: cdjbjgcg.png
Created: 25/Nov/15 11:23 AM
Labels: workflow
Priority: Minor Minor
Reporter: Franziska Ackermann
Originally reported on dspace-tech:

I believe I found a bug related to the "take task" button during the workflow process.

As an administrator, I click on "take task" and the item is assigned to me to be reviewed.
As a non-administrator with workflow step rights (let's say "Reviewer1"), I click on "take task" and get this error:

You are not allowed to perform this task.

Java stacktrace: org.dspace.authorize.AuthorizeException: You are not allowed to perform this task. at org.dspace.app.xmlui.aspect.workflow.FlowUtils.authorizeWorkflowItem(FlowUtils.java:164) at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:155) at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:243) at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3237) at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2394) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:162) at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393) at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2834) at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:160) at org.mozilla.javascript.Context.call(Context.java:538) at org.mozilla.javascript.ScriptableObject.callMethod(ScriptableObject.java:1833)
....

However, the item is assigned to "Reviewer1" in the database. This becomes evident when you reload the submission page. The item will then appear under "Tasks you own".

Do you have any suggestions on how to fix this?


I could verify the error I described earlier on the demo machine (XMLUI, 5.4).
As described below, the error only happens when a user with Workflow-Step rights and without administrator rights tries to take an item from the pool by clicking the "take task" button. (screenshot attached)
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.0.0#70107-sha1:6cd5e8d)
Atlassian logo

Ivan Masár (DuraSpace JIRA)

unread,
Nov 25, 2015, 12:26:00 PM11/25/15
to dspace-...@googlegroups.com

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 10, 2015, 10:21:01 AM12/10/15
to dspace-...@googlegroups.com
Marie-Helene vezina commented on Bug DS-2920
 
Re: AuthorizeException on "take task" during workflow process

My user is both in the WorkflowStep group AND in the Collection Admin group (not super admin though) and it throws the exact same error (i.e. "You are not allowed to perform this task" error message but when submission page is reloaded the task is in fact attributed to the user).

Context: v 5.4 / xmlui / Mirage2

Is there a fix for that?
Thanks

Marie-Helene Vezina
Université de Montréal

Bram Luyten (@mire) (DuraSpace JIRA)

unread,
Dec 10, 2015, 12:33:00 PM12/10/15
to dspace-...@googlegroups.com

Just to be sure, are you using the "traditional" or the "configurable" workflow
https://wiki.duraspace.org/display/DSDOC5x/Configurable+Workflow

If you are not yet on configurable workflow, could you try switching and see if the problem appears on configurable workflow as well?

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 10, 2015, 2:31:00 PM12/10/15
to dspace-...@googlegroups.com

Hello Bram,

I use the plain traditional workflow. Thank you for your suggestion but I'm not quite comfortable in using the configurable workflow as it seems to involve changes in the database structure.... I think I would rather not do that.... but since Franziska A. reported that the same erroneous behavior is seen in the demo web site, maybe a more "traditional" fix should be found? ...will keep searching....

Bram Luyten (@mire) (DuraSpace JIRA)

unread,
Dec 10, 2015, 6:50:00 PM12/10/15
to dspace-...@googlegroups.com

I confirm that the error manifests on demo.dspace.org as well, I was able to recreate the original report by Franziska.

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 11, 2015, 9:53:01 AM12/11/15
to dspace-...@googlegroups.com

One more info: The error doesn't show when, from the main Submission page > Workflow tasks section > Tasks in the pool section, the user clicks on the check box (at the left of the title) and then click on the "Take selected tasks" button at the bottom of the "Tasks in the pool" section. The error only manifests when, after having clicked on the title in order to have a preview of the item, the reviewer can decide to either take the task or leave it.

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 16, 2015, 2:40:01 PM12/16/15
to dspace-...@googlegroups.com

The workaround we found (at least for now) is to force DSpace to look into the database instead of using the cache. Doing so doesn't throw an error.

So in file:

[Source]\dspace-api\src\main\java\org\dspace\workflow\WorkflowItem.java

We have added the one more line:

{{public static WorkflowItem find(Context context, int id)
throws SQLException
{       
// First check the cache
WorkflowItem fromCache = (WorkflowItem) context.fromCache(
WorkflowItem.class, id);       

  • fromCache = null;* // <= this forces Dspace not to use the cache

if (fromCache != null)  

{               return fromCache;  }

}}
(...)

I don't know if intervening with the cache is the right approach to solve this problem but it seems to work for us.

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 16, 2015, 2:40:01 PM12/16/15
to dspace-...@googlegroups.com
Marie-Helene vezina edited a comment on Bug DS-2920
The workaround we found (at least for now) is to force DSpace to look into the database instead of using the cache. Doing so doesn't throw an error.

So in file:

[Source]\dspace-api\src\main\java\org\dspace\workflow\WorkflowItem.java

We have added the one more line:

 {{
public static WorkflowItem find(Context context, int id)

            throws SQLException
       {       
        // First check the cache
       WorkflowItem fromCache = (WorkflowItem) context.fromCache(
                                    WorkflowItem.class, id);        

     *   fromCache = null;*    //  <= this forces Dspace not to use the cache


     if (fromCache != null)  
     {               
      return fromCache; 
     }
}}
 (...)

I don't know if intervening with the cache is the right approach to solve this problem but it seems to work for us.

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 16, 2015, 2:41:00 PM12/16/15
to dspace-...@googlegroups.com

Marie-Helene vezina (DuraSpace JIRA)

unread,
Dec 16, 2015, 2:42:00 PM12/16/15
to dspace-...@googlegroups.com
Marie-Helene vezina edited a comment on Bug DS-2920
The workaround we found (at least for now) is to force DSpace to look into the database instead of using the cache. Doing so doesn't throw an error.

So in file:

[Source]\dspace-api\src\main\java\org\dspace\workflow\WorkflowItem.java

We have added one more line:


 public static WorkflowItem find(Context context, int id)
            throws SQLException
       {       
        // First check the cache
       WorkflowItem fromCache = (WorkflowItem) context.fromCache(
                                    WorkflowItem.class, id);        

     *    fromCache = null; *     //  <= this forces Dspace not to use the cache

     if (fromCache != null)  
     {               
      return fromCache; 
     }

 (...)

I don't know if intervening with the cache is the right approach to solve this problem but it seems to work for us.

Mohamed Mohideen Abdul Rasheed (DuraSpace JIRA)

unread,
Feb 12, 2016, 2:47:00 PM2/12/16
to dspace-...@googlegroups.com

While upgrading DSpace repository from 5.1 to 5.4, I noticed this issue in 5.4. Found the commit that introduces this problem: https://github.com/DSpace/DSpace/commit/0310db74aa71f98ac25aea5f6ab36e0dd3ea4b75 (DS-2614)

Alan Orth (DuraSpace JIRA)

unread,
Nov 30, 2016, 1:30:01 AM11/30/16
to dspace-...@googlegroups.com
Alan Orth commented on Bug DS-2920

We just upgraded from DSpace 5.1 to 5.5 and are now hitting this bug as well. The one-line fix to invalidate the cache check proposed by Marie-Helene Vézina works in our test environment. Can anyone comment on whether this fix is appropriate, or if it might have any side effects?

Bram Luyten (Atmire) (DuraSpace JIRA)

unread,
Dec 10, 2016, 11:29:01 AM12/10/16
to dspace-...@googlegroups.com

Facundo Gabriel Adorno (sedici.unlp.edu.ar) (DuraSpace JIRA)

unread,
Dec 13, 2016, 10:58:01 AM12/13/16
to dspace-...@googlegroups.com

Pascal-Nicolas Becker (DuraSpace JIRA)

unread,
Dec 29, 2016, 2:52:01 AM12/29/16
to dspace-...@googlegroups.com

Pascal-Nicolas Becker (DuraSpace JIRA)

unread,
Dec 29, 2016, 2:55:00 AM12/29/16
to dspace-...@googlegroups.com
Pascal-Nicolas Becker commented on Bug DS-2920
 
Re: AuthorizeException on "take task" during workflow process

Bram Luyten (Atmire)Mohamed Mohideen Abdul Rasheed I went through this in DSpace 6 using a Debugger. The code introduced by the commit mentioned above was barely involved and I doubt it really lead to this problem. Nevertheless I think I got an idea of what's going wrong and will try to fix it.

Pascal-Nicolas Becker (DuraSpace JIRA)

unread,
Dec 29, 2016, 2:55:00 AM12/29/16
to dspace-...@googlegroups.com
Pascal-Nicolas Becker edited a comment on Bug DS-2920
[~bram][~mohideen] I went through this in DSpace 6 using a  Debugger  debugger . The code introduced by the commit mentioned above was barely involved and I doubt it really lead to this problem. Nevertheless I think I got an idea of what's going wrong and will try to fix it.

Tim Donohue (DuraSpace JIRA)

unread,
Feb 3, 2017, 9:53:00 AM2/3/17
to dspace-...@googlegroups.com
Tim Donohue updated an issue
 
Change By: Tim Donohue
Status: Received Accepted

Tim Donohue (LYRASIS JIRA)

unread,
Aug 4, 2021, 3:56:01 PM8/4/21
to dspace-...@googlegroups.com
Tim Donohue closed an issue as Fixed
 

Closing as fixed by DS-3657 (see that ticket for info)

Change By: Tim Donohue
Resolution: Fixed
Status: Accepted / Claimed Closed
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages