feat: User API request to allow admins to submit requests on behalf of users

[kinggeorges12]

Description

Users with the ADMIN permission are now able to request media on behalf of other users. The request appears as if the user themself had requested the content. The endpoint works from POST /user/{userId}/request and has been added to the API-docs. The new functionality allows requests to be routed to the approval queue when an admin submits the requests on behalf of a user, whereas the /request endpoint would automatically approve them.

I created a new endpoint for admins to submit requests on behalf of users, as mentioned in the last post of this thread: #2173

I also fixed a minor bug discovered while testing. The is4k check for MediaRequests caused the API to request multiple times if the is4k parameter was not supplied.

• Fixes #XXXX

How Has This Been Tested?

I tested this on Docker for Windows using Jellyfin v10.11.6 and Jellyseerr develop version (with my committed changes).

Screenshots / Logs (if applicable)

[201: success] When logged in as user with ADMIN permission, executing on another user ID=2:

[403 error: unauthorized] When logged in as a user without ADMIN permission, executing on another user ID=1:

[403 error: unauthorized] When logged in as a user without ADMIN permission, executing on same user ID=2:

[201: success] When requesting via the API authentication:

Checklist:

I ran the translation keys code, but I'm not sure what to do with it. There were no compile errors.

• [X ] I have read and followed the contribution guidelines.
• [X ] Disclosed any use of AI (see our policy)
• [X ] I have updated the documentation accordingly.
• [X ] All new and existing tests passed.
• [X ] Successful build pnpm build
• [? ] Translation keys pnpm i18n:extract
• [NA ] Database migration (if required)

[Copilot]

Pull request overview

This PR enables admins to submit media requests on behalf of other users, allowing requests to be routed through the approval queue rather than being automatically approved. Additionally, it fixes a bug where undefined is4k parameters caused duplicate request issues.

Changes:

• Added new POST endpoint /user/{userId}/request that requires ADMIN permission
• Fixed is4k query bug in MediaRequest entity that caused issues when the is4k parameter was not supplied
• Updated API documentation to include the new endpoint

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
server/routes/user/index.ts	Adds new POST endpoint for admins to submit requests on behalf of users with proper authentication and error handling
server/entity/MediaRequest.ts	Fixes is4k query parameter handling to convert undefined values to false
seerr-api.yml	Documents the new endpoint with request/response schemas and descriptions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[0xSysR3ll]

I ran the translation keys code, but I'm not sure what to do with it. There were no compile errors.

If nothing came out of the command that's because you did not introduce any new string in the UI so don't worry about this.

However, before each commit you must run pnpm:format to fix code formatting issues :)

[kinggeorges12]

I ran the translation keys code, but I'm not sure what to do with it. There were no compile errors.

If nothing came out of the command that's because you did not introduce any new string in the UI so don't worry about this.

However, before each commit you must run pnpm:format to fix code formatting issues :)

It changed line 9 of code in index.ts:

import {
  BlacklistedMediaError,
  DuplicateMediaRequestError,
  MediaRequest,
  NoSeasonsAvailableError,
  QuotaRestrictedError,
  RequestPermissionError,
} from '@server/entity/MediaRequest';

Do I need to do another pull request for this?

[0xSysR3ll]

Do I need to do another pull request for this?

Nope, just push the change.

[fallenbagel]

Thanks for the contribution!

I know this might seem nitpicky, but we do need to address the commit formatting before merging.

Per our contributing guidelines, all commits must follow the Conventional Commits standard (e.g., feat: add feature, fix: resolve bug, docs: update readme).

This is mandatory as this helps us maintain a clean, readable project history and automate our changelog generation. Could you please either amend your commits or squash them into properly formatted ones? And please utilise meaningful commit messages instead of just update file as stated in our contributing guide.

The branch name also doesn't match our convention, but that's fine since you can't change it once the PR is open, but just something to keep in mind for next time.

Once the commits are updated, we'll be happy to review after the feature freeze is lifted. Let me know if you have any questions! 😄

[kinggeorges12]

Thanks @0xSysR3ll . I was able to push the changes recommended by copilot check as well.

[kinggeorges12]

Thanks for the contribution!

I know this might seem nitpicky, but we do need to address the commit formatting before merging.

Per our contributing guidelines, all commits must follow the Conventional Commits standard (e.g., feat: add feature, fix: resolve bug, docs: update readme).

This is mandatory as this helps us maintain a clean, readable project history and automate our changelog generation. Could you please either amend your commits or squash them into properly formatted ones? And please utilise meaningful commit messages instead of just update file as stated in our contributing guide.

The branch name also doesn't match our convention, but that's fine since you can't change it once the PR is open, but just something to keep in mind for next time.

Once the commits are updated, we'll be happy to review after the feature freeze is lifted. Let me know if you have any questions! 😄

OK that was a journey, but I think I squashed the commits and renamed them suiting the preferred style.