Add field layout rules

[Rob Guttman]

In the latest version (see #7674), there are no longer gaps in the fields table when fields are hidden - instead the fields are "collapsed" into the gaps.

The new problem this now creates is that fields may no longer remain in the same columns or appear in relative positions to each other. For example, it may be easier for users to always have, say, the Version field just under the Milestone field, or the Queue field in the left column and the Queue Position field immediately to the right of it in the right column.

Adding some simple layout options would be a means to express the desired layout:

field1.above = field2
field3.before = field2
field4.column = left

The above is just an example interface.

[Rob Guttman]

As it turns out, this is not an easy problem to solve. If there's no need to preserve the original ordering when possible, then this becomes a CSP (constraint satisfaction problem)> However, since the original ordering should be preserved when possible, it becomes a linear programming problem.

So any solution would likely require additional python modules and would need to fail gracefully if not present.

[Steffen Hoffmann]

Replying to robguttman:

.. Adding some simple layout options would be a means to express the desired layout:

field1.above = field2
field3.before = field2
field4.column = left

The above is just an example interface.

Sure, but how about using existing semantics? At least for the after/before part (common low-to-high-order intended):

field3.order = 1
field2.order = 2
field1.order = 0

The above/below and force(column) options look just fine to me. But with such high degree of control over display there are a lot of invalid configurations that needs to be dealt with, i.e. mutual exclusive statements and lots of higher order circular dependencies involving different relation typs, that may not be trivial to check/handle, like the following (still easy) example:

field1.above = field2
field1.order = 1
field2.above = field3
field3.order = 0

[Rob Guttman]

The existing semantics of field ordering would still be used and would be honored only after all above/below/column constraints are satisfied as those take precedence. You can think of the above/below/column rules as hard constraints and field ordering rules as soft constraints which can be relaxed as needed.

Where the hard constraints over-constrain the problem, I could either abandon all constraints and report an error or arbitrarily and incrementally relax constraints until the problem is no longer over-constrained.

This feature likely not worth the effort to implement except that it gives me an excuse to try my hand at a tricky and fun LP problem.

[Steffen Hoffmann]

Replying to robguttman:

![...] This feature likely not worth the effort to implement except that it gives me an excuse to try my hand at a tricky and fun LP problem.

Sure, I'd do it same way. After all configuration is done rarely on a regular basis, while your plugin is great in constantly adapting ticket view/editor to admin and user's liking. So any sort of highly sophisticated fall-back handling is pure admin convenience. Just make sure, that the otherwise very comfortable (pref) capability is not inherited to this options, so that no user could manage to cause a DoS by random/weird configuration, even not for himself-only.

[Ryan J Ollos]

Closing old ticket as out-of-scope for this plugin. Will reconsider if someone makes the request.