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.