Fix missing impersonate headers on bitstream uploads (e.g., /mydspace drag-and-drop)

[MMilosz]

References

• Fixes When impersonating an eperson, submissions cannot be start by uploading a file. #6255 (commit 37b870c)

Description

When an admin impersonates another user, some upload requests were missing the X-On-Behalf-Of header on several code paths.

This PR ensures the impersonation header is set on every upload path, i.e.:

1. /mydspace -> starting a submission via drag-and-drop (fixes When impersonating an eperson, submissions cannot be start by uploading a file. #6255)
2. in-progress submission -> replacing a file (7396dc3)
3. bitstream page -> replacing a file (7396dc3)
4. edit-item page -> uploading a new bitstream (7396dc3)
5. community/collection edit -> uploading a logo (0545041)

The header is set via this.uploadFilesOptions.impersonatingID = this.authService.getImpersonateID();, mirroring the existing approach in submission-form.component.ts

Before

After

Instructions for Reviewers

How to Test

To Impersonate: Log in as admin, go to Access Control -> People -> Edit any submitter (user with submit permissions) -> press the Impersonate button.

To Replace a Bitstream: this requires REST API having replace-bitstream.enabled = true (which is not present in sandbox.dspace.org)

Test 1 (fixes #6255)

1. Go to /mydspace and drag-and-drop any file onto the page. Select any collection
2. Observe edit page opens, no infinite spinner

Test 2 & 3 - replacing a bitstream (in-progress submission & bitstream page)

Ensure your DSpace API has replace-bitstream.enabled = true (not present in sandbox). This allows you to replace a bitstream through the item page or during submission. Test both paths (reference: #4368).

Observe no errors on upload. In Network tab, confirm both X-On-Behalf-Of, X-Xsrf-Token headers are present

Test 4 - edit-item page

1. Impersonate a user with edit rights on an archived item.
2. Open the item -> Edit tab -> Bitstreams tab. Open DevTools -> Network.
3. Upload a new file to the ORIGINAL bundle.
4. Observe no errors. In Network tab, confirm both X-On-Behalf-Of, X-Xsrf-Token headers are present

Test 5 - community/collection logo

1. Impersonate a community/collection admin
2. Edit their community. Open DevTools -> tab Network. Upload a logo
3. Observe no errors. In Network tab, confirm both X-On-Behalf-Of, X-Xsrf-Token headers are present

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR follows all coding best practices based on the Code Conventions Guide
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.