feat: Add configurable auto-approval

[augustuen]

Description

Add the ability to define "rules" for auto-approval, instead of the simple yes/no system from before.

Features:

• Approve requests based on defined conditions
• Modify users' requests according to the set rule before approving them
  • Ex: If a movie has the christmas tag, change the root folder to christmas_movies

Screenshot (if UI-related)

To-Dos

• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

[fallenbagel]

Suggestion: Move this to settings page as a tab. As this is 100% a setting

[gauthier-th]

It could be cool to have the same rule system as the override rules one: #945
With that we could improve/edit the "rules editor" at the same time for both rules system.

(But we could do it in another PR)

[augustuen]

Oh, I wasn't aware that existed! That looks really awesome. One thing I would've liked is the ability to send a notification without approving the request, but I don't see it as an absolute necessity.

With "same rule system", do you mean to use the same component for both? Or something in the backend?

[gauthier-th]

With "same rule system", do you mean to use the same component for both? Or something in the backend?

Probably more for the frontend, but if you can think of something clean for the backend it could be useful too (as long as the abstraction for the "rule system" doesn't make things more complicated)

[augustuen]

Idk if this is genius or moronic (though I'm leaning towards the latter), but: The edit modal has basically a list of variable length of different kinds of conditions, which have different UIs (some have text boxes, others have multi-selects), and I'm trying to make adding new conditions later on as simple as possible, so I had the idea of putting the UI and the logic together in the same class.

Basically, it's this:

  [...]
  public boolean isSatisfiedBy(MediaRequest request){
    (...)
  }
  public Component = () => {
    return(
      <GenreSelector
        type='tv'
        defaultValue={value}
        isMulti
        onChange={...}
       />
    );
  }
}

Both isSatisfiedBy and Component are inherited from the base, with isSatisfiedBy being called by the API/backend to process an incoming request, and Component being used in the edit modal. This would in theory mean that the core code wouldn't have to be changed to accomodate new condition types (specifications) later on, since it would focus on AutoApprovalSpecificationBase, and leave it up to the specifications themselves to decide whether a request satisfies it, and to provide the UI components that they need.

IMO, this would consolidate it into a neat little package, but I can also see it being convoluted/messy/just generally bad practice to mix logic and UI in this way.

[gauthier-th]

To be honest i'm not exactly sure what you mean by this mix of UI and logic, but feel free to send the updates in this PR and i'll review it.
Just my 2c about the system to better handle conditions later: i don't think this is necessary, as i doubt we'll add new conditions very often.

[augustuen]

To be honest i'm not exactly sure what you mean by this mix of UI and logic, but feel free to send the updates in this PR and i'll review it.

Basically, instead of having two parts, e.g. UserSpecification and UserSpecificationComponent, one for the backend logic and one for the UI component, we'd just have UserSpecficication with a Component member (i.e. UserSpecification.Component). That way we'd be able to just assign the specific values to one object, and we wouldn't have to have a check in every UI bit for what sort of specification/condition it is and which UI component should be used.

Unfortunately, I've already moved away from this, because I tried it myself and got an issue that seemed to relate to trying to use UI components in a server object.

Just my 2c about the system to better handle conditions later: i don't think this is necessary, as i doubt we'll add new conditions very often.

That's fair, but to be fair I also figured it could simplify adding the conditions currently, instead of having to go through and update the UI components with every added condition.

Also, if possible, I'd like to ask you some questions on Discord about how Jellyseerr works/is built. I don't think they're necessary to include here in the PR.

[gauthier-th]

That's fair, but to be fair I also figured it could simplify adding the conditions currently, instead of having to go through and update the UI components with every added condition.

If the result is simpler yes go ahead.

Also, if possible, I'd like to ask you some questions on Discord about how Jellyseerr works/is built. I don't think they're necessary to include here in the PR.

Sure, feel free to reach us in the #development channel