share submission normal user -> normal user

[kosarko]

When clicking the "Take it" button user gets an error "An error occurred while changing the submitter". It doesn't matter if the user is an admin or not.

The dev tools show:

ie the workspaceitemid is undefined

[amadulhaxxani]

After more testing, it turns out the original "workspaceitemid=undefined" only happens when the url is wrong, or has no id in the params. The real issue is permission‑based: a user can only take over a submission if they have submit rights to the collection. (not exactly the issue but maybe needs better handling for showing nicer error message)

• When the target user has submit rights → takeover works ✅
• When the target user lacks submit rights → backend returns 403 ❌

[milanmajchrak]

Would it be possible to write down the steps to reproduce it? We’ll add them to the test scenarios.

[amadulhaxxani]

@milanmajchrak

Please let me know if I need to re-edit the description of this task or the comment would work fine for now!

Prerequisites

• frontend is running and accessible at http://localhost:4000.
• Users exist and can authenticate:
  • admin@test.edu (admin)
  • user1@test.edu (regular user)
  • user2@test.edu (regular user)
• At least two collections exist with different submit permissions:
  • Collection A: both user1@test.edu and user2@test.edu have submit rights.
  • Collection B (or equivalent): user1@test.edu does not have submit rights.
• Workspace items exist in those collections (for example: workspaceitemid=972, 974, 976, 978).
• Users can access the Submissions page and use the Share action.

Setup Steps

1. Log in as a sender user (admin or regular user).
2. Go to Submissions.
3. Select a workspace item.
4. Click Share to generate a takeover link in this format:
   • http://localhost:4000/share-submission/change-submitter?share_token=TOKEN&workspaceitemid=ID
5. Copy the generated link.
6. Log out.
7. Log in as the intended recipient.
8. Open the copied link.
9. Click Take it.
10. Observe the result (submission transferred or access denied).

Test Cases

TC-126-01: user1 shares with user2 (both have rights) - should succeed (Tested the vice versa and it also works)

• Sender: user1@test.edu
• Recipient: user2@test.edu

TC-126-02: user1 shares with admin (admin has rights) - should succeed (Tested the vice versa and it also works)

• Sender: user1@test.edu
• Recipient: admin@test.edu

TC-126-03: Admin shares with user1 with valid rights - should succeed

• Sender: admin@test.edu
• Recipient: user1@test.edu

TC-126-07: Admin shares item in different collection access group - should fail

• Sender: admin@test.edu
• Recipient: user1@test.edu

"For each test case, follow the Setup Steps 1-10 using the specified sender and recipient. Verify the expected outcome (succeed = submission transferred, fail = 403 error)."

Notes

• Core rule validated: takeover succeeds only when recipient has submit rights for the workspace item's collection (or is admin).
• Failure mode observed for unauthorized recipient is 403 Forbidden.
• Tokens are scenario-specific; links must include a valid share_token and workspaceitemid.

[kosarko]

• When the target user lacks submit rights → backend returns 403

@amadulhaxxani what is the error message? Is it something generic or does it mention the lack of rights on the collection?

[amadulhaxxani]

@kosarko I don't think it mentioned the lack of rights :)
EndPoint:

http://localhost:8080/server/api/submission/setOwner?shareToken=4a011efb208042b3972832bd8c129c5d&workspaceitemid=979

Response:

{
    "timestamp": "2026-03-30T07:58:30.318+00:00",
    "status": 403,
    "error": "Forbidden",
    "message": "Access is denied",
    "path": "/server/api/submission/setOwner"
}

and on the UI it simply says:

> An error occurred while changing the submitter