Test the adding of NZB's more extensively

[Safihre]

One of the things that isn't covered, but has given me troubles over the past few years is the adding of NZB's and all the checks performed there. In particular selecting the right priority if duplicate detection and/or pre-queue scripts are active. And the different situations based on what is set by the category and manual input. @jcfp you did some extensive api testing recently, can we easily add this as a functional set of tests? Or should it be unit tests?

[jcfp]

Functional tests I'd say, as this is mainly about interaction between various choices/settings/input. Looks doable, afaict all relevant actions and settings (adding nzbs, scripts, duplicate-related stuff, categories) are available via the api. Could give it a go myself if this isn't too urgent.

Any scenarios or combinations of settings that are particularly troublesome?

[Safihre]

I was hoping you'd have time, indeed no rush! The combination of supplying either -100 (default) and having a Pre queue script that sets a priority. Then a category set from Pre queue that has a deviating priority from Default. And maybe what happens if on top of that a non-Default priority was supplied when adding the NZB, I think it should override the others, but maybe it doesn't. 😅

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jcfp]

[jcfp]

Got some work done on this one, which resulted in a couple of questions:

• Should a priority set upon adding the job ever get precendence over a later priority assignment?
• When setting a category from pre-q without explicitly setting a priority, should the job inherit the prio from that category?
• When setting a priority intended to modify the job state (such as Paused); what prio is supposed to be used after the job state gets set? Category-based, Default, always Normal, whatever is was before it was set to Paused, something else...?
• What is -100 (default) supposed to refer to; should it take into account category and/or any previous priority assignments?

[Safihre]

• I think a priority-set-when-adding should always have precedence.
• Yes.
• What it was before it was paused, so most likely category based or something that came out of the pre-queue.
• -100 should just take the category one or the pre-queue'd one.

At least that's what I think, what do you think?

[jcfp]

I agree for the most part, with the exception of priority-on-adding for which I don't see a good reason to let that override later (attempted) changes to the priority. But since you specifically mentioned that one in a comment and I didn't see it getting special treatment in an early test setup, I figured I better ask anyway.

The straightforward stuff mostly behaves as expected so far (still investigating an issue with implicit/category prio from pre-q though). The last two of my Qs at least in part come down to developer choices, but your answers pretty much match with what I consider logical and expected behaviour.

[Safihre]

For the priority on adding, maybe should only be overruled if the Pre queue script specifically sets one? So not overruled by category for sure.

[jcfp]

All right, I'll assume that.

[Safihre]

Closed by #1760