Submitter shows "N/A" for workflow editors (bug?)

206 views
Skip to first unread message

Igor Baptista Da Costa

unread,
Feb 5, 2024, 7:41:43 AM2/5/24
to DSpace Technical Support
Hello,

I found something that I think is a bug, but Im not sure.

When using a normal account that is part of a workflow editor groups (WORKFLOW_STEP_2 groups) for some collection, in /mydspace when access "Workflow tasks" I cannot see the submitter of the item, it shows only "N/A". I can only see the submitter if the account is workflow editor + system administrator.

In my perception the workflow editor should be able to know who is the submitter of the item because it can be a factor to accept or reject the submission.

How to reproduce:
-> have two accounts, one system administrator and one normal account
-> create a collection
-> create the workflow editor group and add both accounts as workflow editor for a collection
-> submit an item for this collection
-> go to MyDSpace page and click in "Workflow tasks" in both account, in the account that is sysadmi + workflow editor you should be able to see the submitter, in the account that is a normal account + workflow editor the submitter shows as "N/A".

The endpoint that return the data about the submitter is: /server/api/workflow/workflowitems/{ID}/submitter, for the normal account + workflow editor the response body is empty and the http response is 204.

Thanks in advance!

Igor Baptista Da Costa

unread,
Feb 5, 2024, 12:46:13 PM2/5/24
to DSpace Technical Support
Oh, I forgot to mention, this behavior happens in dspace 7.6

DSpace Technical Support

unread,
Feb 9, 2024, 12:14:18 PM2/9/24
to DSpace Technical Support
Hi,

This does sound like a possible bug.   My recommendation would be to try to reproduce this on our demo site at https://demo.dspace.org/   If you can reproduce the problem there, then it's definitely a bug.  If not, then that may imply that either it's a problem specific to your site or maybe you have some sort of unique data that is encountering an unexpected scenario.

I can verify though that in the UI, if the "submitter" information is missing or empty, then the value of "N/A" is returned instead.  It's possible that there's a permissions error here where this information is currently restricted to full Admins.

In any case, you are welcome to create a bug report and we can look for a volunteer to dig in further.  https://github.com/DSpace/DSpace/issues (If you can reproduce it on the demo site, that's definitely proof this would be a bug.)

Tim

emilio lorenzo

unread,
Feb 9, 2024, 12:37:57 PM2/9/24
to dspac...@googlegroups.com

we are "suffering"    this behaviour in one installation.  Still defining  more precisely the scenario.  Probably a bug...

Emilio

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/b69d6fb4-f51a-406a-b15d-a392450cd06bn%40googlegroups.com.

Daniel Pais

unread,
Apr 4, 2024, 2:07:43 PM4/4/24
to DSpace Technical Support
Good afternoon!

We tested the submitter in the demo, in a scenario where one account was only a submitter and the other was only a reviewer to avoid privileges and test the correct scenario. In these terms, it was possible to see the submitter in the evaluation flow. We then analyzed the demo version of DSpace and found it to be 7.6.2-SNAPSHOT. When consulting git, it would appear to be the "dspace-7_x" branch. We installed this branch in a local environment and ran the same test, but got different results. Locally the submitter appeared as "N/A". We also noticed a change from the demo to the local environment, users with the same permissions in both environments had variations in the administrative panel: in the demo it was possible to create, edit and view groups; In our local environment with (in theory) the same version of DSpace, the user only had the possibility of creating a new item; remembering that the two users in both environments were created in the same way and with minimum privileges.

Has there been anything issued to correct this issue? In which branch can I find the same modifications that are found in the demo?

Thank you in advance,
Reply all
Reply to author
Forward
0 new messages