Opened 8 years ago

## #7730 new enhancement

Reported by: Owned by: Rob Guttman Rob Guttman low DynamicFieldsPlugin minor ticket view field position 0.11

### Description

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.

### comment:1 Changed 8 years ago by 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.

### comment:2 in reply to:  description Changed 7 years ago by Steffen Hoffmann

Keywords: ticket view field position added

.. 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


### comment:3 follow-up:  4 Changed 7 years ago by 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.

### comment:4 in reply to:  3 Changed 7 years ago by Steffen Hoffmann

![...] 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.

### Modify Ticket

Change Properties