feat: Allow admin/owner to opt out of auto-approval

[fronc]

Description

This PR implements an option for admin and owner accounts to disable auto-approval of their own requests, addressing a long-standing feature request. Admin requests can now go through the normal pending → approved flow, enabling integration with third-party tools and manual queue management.

Why is this change required? Currently, any request made by an admin or owner account is automatically approved and begins processing immediately. This behavior:

1. Prevents wishlist functionality - Admins cannot maintain a queue of desired media
2. Breaks third-party tool integration - Tools that intercept pending requests (for availability checking, approval workflows, etc.) cannot process admin requests
3. Limits admin flexibility - Features are more restricted on accounts with greater permissions

What problem does it solve? This change allows admins to opt out of auto-approval while preserving all existing administrative permissions and functionality. It also fixes a typo in watchlist sync that prevented TV watchlist items from creating requests.

Key Changes:

• Modified server/lib/permissions.ts to treat auto-approve permissions explicitly for admin users
• Updated server/entity/MediaRequest.ts to remove Permission.MANAGE_REQUESTS from auto-approval status check
• Added special handling in server/routes/user/usersettings.ts for owner to modify their own auto-approve permissions
• Updated frontend components to allow owner to toggle auto-approve in UI
• Fixed typo in server/lib/watchlistsync.ts (AUTO_APPROVE_TV → AUTO_REQUEST_TV)

Permission Behavior:

• Admin bypass preserved for all non-auto-approve permissions (MANAGE_, REQUEST_, VIEW_*, etc.)

• Auto-approve permissions (AUTO_APPROVE*) now require explicit grant, even for admins

• All other administrative functions continue to work as before

• Fixes [Feature Request] Option to disable auto approve for admin and owner accounts #191

Note: This PR description was generated by a heavily scrutinized Claude Code based on very detailed requirements by the code author. Coding assistance was also provided by CC, although this too was closely supervised and always read and understood before each change was implemented. Some code and how to address the problem was also inspired by an Overseerr fork by @ohmzi.

How Has This Been Tested?

Testing Environment:

• Local development environment
• Docker container deployment
• Multiple user roles (admin, owner, regular user)

Functional Tests Performed:

• ✅ Non-admin users can log in (/auth/me returns 200)
• ✅ Admin users can log in
• ✅ Admin with auto-approve disabled → requests go to PENDING
• ✅ Admin with auto-approve enabled → requests auto-approve
• ✅ Admin can still approve/reject other users' requests
• ✅ Admin can still manage users, settings, issues
• ✅ Owner can toggle auto-approve permissions in UI
• ✅ Owner cannot modify other permissions on themselves
• ✅ Notifications still work for admins
• ✅ Watchlist sync creates requests correctly

Edge Cases Verified:

• ✅ hasPermission(0, ...) returns true (any logged-in user)
• ✅ hasPermission([], ...) returns true (empty array)
• ✅ hasPermission([AUTO_APPROVE], ...) requires explicit bit for admin
• ✅ hasPermission([MANAGE_REQUESTS], ...) allows admin bypass

Comprehensive Permission Audit:
All permission behaviors preserved with one intentional change:

• Non-admin login: ✅ Works
• Admin login: ✅ Works
• Admin creates request: ✅ Goes to PENDING (if auto-approve disabled)
• Admin approves others' requests: ✅ Works
• Admin manages users: ✅ Works
• Admin changes settings: ✅ Works
• Owner edits auto-approve: ✅ Can toggle
• Owner edits other permissions: ✅ Blocked
• Non-owner edits owner: ✅ Blocked
• Watchlist sync: ✅ Creates requests

Screenshots / Logs (if applicable)

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract - Not required, no new UI text added
• Database migration (if required) - Not required, no database schema changes

Summary by CodeRabbit

Release Notes

• Improvements
  • Refined auto-approval logic to operate independently of admin management permissions, enabling better third-party tool integration.
  • Modified admin bypass behavior—auto-approve permissions now require explicit permission checks instead of automatic admin elevation.
  • Updated server owner permission controls to focus exclusively on auto-approval settings.

[fallenbagel]

Please update the pr description with the proper pr template.

[fronc]

Please update the pr description with the proper pr template.

Thank you, and apologies - I really did search for this before submitting. But after looking again and reviewing the Contributions docs, I still cannot find a template anywhere. Could you please direct me to the appropriate resources?

[M0NsTeRRR]

The template is here : https://github.com/seerr-team/seerr/blob/develop/.github%2FPULL_REQUEST_TEMPLATE.md

[fronc]

Thank you! I've updated accordingly and added screenshots. Hope this helps!

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

This PR decouples auto-approval permissions from admin management permissions across the permission system. Changes remove MANAGE_REQUESTS from auto-approval checks in media request processing and UI components, introduce conditional admin bypass logic that excludes auto-approve permissions, and allow owners to selectively disable auto-approval while preserving other permissions.

Changes

Cohort / File(s)	Summary
Core Permission System server/lib/permissions.ts	Refactored hasPermission logic with new isAutoApprovePermission helper; admin bypass now conditional and excludes auto-approve permissions; added array-based permission check support with special handling for auto-approve permissions; parameter renamed value → userPermissionValue.
Backend Media Request & Settings server/entity/MediaRequest.ts, server/routes/user/usersettings.ts	Removed MANAGE_REQUESTS from auto-approval checks in media request entity; introduced AUTO_APPROVE_BITS constant; added special case allowing Owner (id 1) to modify only auto-approve bits in own permissions while preserving others.
Frontend Permission Components src/components/PermissionOption/index.tsx	Introduced isAutoApprove flag for auto-approve permissions; owner exemption and admin bypass now exclude auto-approve permissions; removed automatic granting of all auto-approve permissions when MANAGE_REQUESTS is present; retained parent-child selection behavior.
Frontend Request Modals src/components/RequestModal/CollectionRequestModal.tsx, src/components/RequestModal/MovieRequestModal.tsx, src/components/RequestModal/TvRequestModal.tsx	Excluded MANAGE_REQUESTS from auto-approval permission sets in auto-approval determination logic; added comments explaining intentional exclusion to allow third-party interception.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 Hops through permissions with glee,
No more auto-approve decree!
Admins now choose their own way,
Wish lists live another day!
Smart controls, wild and free! 🎉

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Allow admin/owner to opt out of auto-approval' clearly and accurately summarizes the main objective of the changeset, which is to enable admins and owners to disable auto-approval of their own requests.
Linked Issues check	✅ Passed	The PR fully implements the feature requested in issue #191: allowing admins and owners to disable auto-approval by modifying permission handling, UI controls, and media request logic to exclude MANAGE_REQUESTS from auto-approval checks.
Out of Scope Changes check	✅ Passed	All changes are directly related to the auto-approval opt-out feature. Permission logic modifications, UI toggles, and media request checks all support the core objective.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[fronc]

I believe this is now ready to be merged. Please review at your earliest convenience and let me know if you'd like to discuss it any further before doing so. Thanks!

[gauthier-th]

I don't see the benefit of this PR. It is normal and intentional that admins do not have to approve themselves a request that they have just sent.

It is approved directly by design; it would be counterintuitive to do otherwise. If you absolutely want to have this approval system, why not create a user account without administrator permissions for your personal use?

@fallenbagel wdyt?

[fronc]

I don't see the benefit of this PR. It is normal and intentional that admins do not have to approve themselves a request that they have just sent.

It is approved directly by design; it would be counterintuitive to do otherwise. If you absolutely want to have this approval system, why not create a user account without administrator permissions for your personal use?

@fallenbagel wdyt?

Thanks for the feedback! I'd like to address the "just use a non-admin account" suggestion, as this is actually the core of why this feature request exists in the first place (see #191).

Third-party queue management tool integration is currently broken by design for admins only Tools like Availarr and similar automation tools work by intercepting pending requests. Because admin requests are auto-approved and bypass the pending state entirely, those tools simply never see them.

Using a second, non-admin account (as you suggest) isn't a viable workaround because an admin shouldn't have to log out of their own account and into a second one every time they want to make a personal request. That's not really a workaround, it's just moving the friction somewhere else while making the overall experience worse.

As the original feature request puts it: features shouldn't be more limited on an account with greater permissions. Having to maintain two separate accounts - one for administration and one to actually use the service you're running - is a frustrating and unnecessary limitation.

This PR addresses that by making auto-approval something admins can explicitly opt out of, rather than a hardcoded behavior. All other admin capabilities are fully preserved.

[gauthier-th]

Yes I get the disadvantage of logging in / out with an admin account and a normal account.

The main issue you raise is the integration of admin accounts of Seerr with third-party tools. Because these tools integrate poorly with admin accounts, should Seerr be the one modified to adapt to their flawed logic? To be honest I don't really like that idea.

[fronc]

With due respect, I don't see it as flawed logic. It's highly valuable to run checks on requests against places the content already exists. That check inherently exists between request and fetch. Auto-approving inherently clashes with that. There is no reason that I can see why providing admins with this capability (and defaulted the same as before) is a bad thing. Admins should be able to use the same tools and features they set up for their users.

Is there a different issue or problem I'm not addressing which makes this bad for Seerr? I feel the request followed protocol, addresses a specific issue, and does so without over engineering a solution, so I'm dismayed that it's being closed without more of a discussion.

[sct]

If you can't even bother to comment on your own without using AI, or write your own PR, then I'm not confident you actually understand the changed code. I would close this PR on that basis alone. But even with that said, I agree with @gauthier-th here. I'm sorry Seer's design doesn't work well with your third-party tools, but we shouldn't have to change our design to accommodate them. Admins being auto-approved has been a design decision we have chosen to stick by for 5+ years. It's not going to change.

[fronc]

I seem to have offended folks here, which was not my intent. I was transparent about the use of Claude code from the start, but even though I'm not an SWE by profession, I do operate responsibly, and understood every line of code that was changed. If use of AI tools is flatly prohibited, then I do politely suggest the project update its rules so folks like me know not to bother trying.

I really was excited to be able to contribute to this project, and I feel I addressed all of your concerns. The only one I can't do anything about is an unwillingness to change. Despite requests for this in both the Overseerr and Seerr repos, I don't know how else to change your mind to see that optionality here enhances the product, and the past doesn't need to dictate the future.

I'm open to hearing how I can be a better collaborative partner to you (and to other projects) in the future, and sorry this comment thread went sideways, to whatever extent I've caused that.

[dkenpachi246]

I seem to have offended folks here, which was not my intent. I was transparent about the use of Claude code from the start, but even though I'm not an SWE by profession, I do operate responsibly, and understood every line of code that was changed. If use of AI tools is flatly prohibited, then I do politely suggest the project update its rules so folks like me know not to bother trying.

I really was excited to be able to contribute to this project, and I feel I addressed all of your concerns. The only one I can't do anything about is an unwillingness to change. Despite requests for this in both the Overseerr and Seerr repos, I don't know how else to change your mind to see that optionality here enhances the product, and the past doesn't need to dictate the future.

I'm open to hearing how I can be a better collaborative partner to you (and to other projects) in the future, and sorry this comment thread went sideways, to whatever extent I've caused that.

I'm 100% with you here, this change being totally OPTIONAL to the end user takes nothing away from this project.

[fronc]

I'm 100% with you here, this change being totally OPTIONAL to the end user takes nothing away from this project.

Conversation taking place on discord. Please stay respectful and productive as we try and figure out a solution that benefits everyone and moves the project forward.

[j0hnm4r5]

Context on why this was closed:

This PR (#2245) implements an opt-in toggle allowing admin/owner accounts to disable auto-approval of their own requests. The feature was off by default, preserved all existing behavior, passed automated review, and was kept current with the develop branch over several months.

The maintainers closed it on the grounds that auto-approval for admins is an intentional, long-standing design decision they don't intend to change. The suggested workaround is to use a separate non-admin Plex account for personal requests.

For anyone arriving here from issue #191 or sct/overseerr#3926: the use cases — allowing admin requests to pass through the pending state for wishlist management or third-party tool integration, allowing for the use of a single admin account shared between multiple users, and allowing the admin to control when a request is approved for reasons like limited disk space or bandwidth — remains unaddressed and, per the maintainers, will not be addressed in this project. The discussion took place on GitHub and in the Seerr Discord #development channel around February 21–22, 2026.

[ohmzi]

If you can't even bother to comment on your own without using AI, or write your own PR, then I'm not confident you actually understand the changed code. I would close this PR on that basis alone. But even with that said, I agree with @gauthier-th here. I'm sorry Seer's design doesn't work well with your third-party tools, but we shouldn't have to change our design to accommodate them. Admins being auto-approved has been a design decision we have chosen to stick by for 5+ years. It's not going to change.

very open source way of talking. "It's not going to change."
sct/overseerr#3926
#191

we got more than enough poeple asking for this feature. but "It's not going to change."
bravo!

[ohmzi]

@fronc can you please keep your forked branch up-to-date, whenever you get a chance. i'll be using that to install seer onwards.

suggest other people do the same until the "It's not going to change." mindset changes.

[fallenbagel]

very open source way of talking. "It's not going to change."
sct/overseerr#3926
#191

we got more than enough poeple asking for this feature. but "It's not going to change."
bravo!

Open source means the code is open for anyone to use, fork, and modify, which is exactly what you're doing, and that's completely fine. What it doesn't mean is that maintainers are obligated to merge every feature request or PR that comes in.
We make design decisions based on what we believe is best for the project as a whole.

Sometimes that means saying no to things people want. That's not a "mindset" problem, that's how every maintained project works, open source or otherwise. External contributors aren't the ones responsible for maintaining this codebase long-term, we are. That's true for every project, and it's exactly why maintainers have the final say on design direction

The admin auto-approval behavior is an intentional design choice. "It's not going to change" isn't us being dismissive or going against open source philosophy, it's a very transparent answer from the maintainers who design, develop, and maintain this codebase for the long-term. We'd rather be upfront than string people along.

Seerr is designed to work as its own project. We shouldn't have to change our design language to accommodate third-party tools, if anything, it should be the other way around.

You're welcome to use a fork. That's literally what open source enables. But mischaracterizing a clear design decision as some kind of failure of open source values isn't productive. And since there are no productive discussions left, I am locking this thread.