Add move method to automation rule

[stsewd]

This is needed to re-organize rules
without explicit changing all priorities
or changing one by one

I just need to add tests for negative steps, and add a comment why just doing an .update(F('priority') + 1) doesn't work

[stsewd]

Oops, I use the manager introduced in #5995, that PR should be merged first

[humitos]

What does it mean to "move an automation rule N steps"?

[stsewd]

@humitos if you have this rules

1. One
2. Two
3. Three

The automation rules are run in that order (according to their priority). User can rearrange the rules to change the order they are run. Like

1. Three
2. One
3. Two

Users shouldn't need to update each priority version one by one. Think of it like a drag and drop thing

[humitos]

I feel this implementation is too complex and does not manage moving one step up (like steps=-1, at least in the tests).

I think we can implement this in a simpler way:

1. query all the Automation Rules sorted by priority
2. get the index of the one that we want to move from that list
3. move that Automation Rule where it should be in the list (steps)
4. set the index of each Automation Rule in the list as priority

So, we will end up always with 0, 1, 2, 3 as priority if we have 4 rules, instead of dealing with weird priority numbers.

[stsewd]

I feel this implementation is too complex and does not manage moving one step up (like steps=-1, at least in the tests).

It does, tests are still missing. It's on the description.

move that Automation Rule where it should be in the list (steps) set the index of each Automation Rule in the list as priority

We can't save the values like that, it breaks the constraint of unique (project, priority)

So, we will end up always with 0, 1, 2, 3 as priority if we have 4 rules, instead of dealing with weird priority numbers.

Current implementation always keeps the range, it doesn't add weird numbers

[humitos]

We can't save the values like that, it breaks the constraint of unique (project, priority)

Why it will break that constraint if we will have priorities like 0, 1, 2, 3, 4 tied to one project?

Current implementation always keeps the range, it doesn't add weird numbers

This is the weird number that I was reffering to: https://github.com/readthedocs/readthedocs.org/pull/5998/files#diff-763de362f34a86b264903b372e7dd27fR1012

[stsewd]

This is the weird number that I was reffering to

That's is temporary, to avoid the unique constraint

Why it will break that constraint if we will have priorities like 0, 1, 2, 3, 4 tied to one project?

In the final result not, but in the intermediate steps, when you try to save or update an object, other object will have the same priority. That's why I can't use just one update in the current code and need to iterate over each object.

[stsewd]

This is ready for review. This is on top of #5995 (that should be merged first)

[stsewd]

I also overrode the delete method to keep the priority numbers the same after delete

[ericholscher]

What happens if we hit an exception here? The rule will be stuck with a broken priority. We likely need this to happen in some kind of DB transaction to avoid bad states here.

This feels really complicated and brittle. I don't have a better suggestion currently, but I'm wondering if this concept of priority is something we need to enforce so strongly.

[stsewd]

We have transactions per request

readthedocs.org/readthedocs/settings/base.py

Line 33 in 59738a1

ATOMIC_REQUESTS = True

So, we need to have a unique priority in all rules of a project, that way they get sorted how the user wants.

We can remove the unique constraint as Manuel suggested, and maybe check for inconsistencies on save?

[ericholscher]

Yea, I guess we can keep this for now, but I'm guessing it will cause issues at some point :)

[humitos]

I'm not happy with the implementation, but feel free to merge if you want. @ericholscher already approved it 😄. Although, ...

I think that having the constrain at the db level for this just makes our lives harder and does not gives us too much benefit, since the order/priority will always set programmatically (not manual).

I feel it's easier to maintain all this code (with a simple implementation) if we just remove the constrain from the db.

#5998 (review)

[ericholscher]

I like having the DB restriction though. I don't trust code not to mess it up, and then we'd end up with weird bugs. This will lead to different weird bugs, but at least these weird bugs will be understandable :)