[Feature Request] Custom order of nested fields

[dnbsd]

We have an object tool in our project fields with nested fields name, version, description.

When creating a report the fields are ordered according to the alphabet. Although logical, it makes reporting cumbersome as we have learned to expect a natural order of the fields. At the moment, two solutions are possible:

1. Add a number prefix to a nested field id

For instance:

_01_name
_02_version
_03_description

This however, requires changing the template if the order changes or a new nested field is added.

2. Use a flat hierarchy

Instead of an object use multiple fields with a common prefix, for instance:

tool_name
tool_version
tool_description

I don't like this approach as it pollutes the section with too many fields. Also, this approach won't work with variable number of tools (a list of objects).

Ideal solution would be to keep the order in which they were added, and then allow ordering via drag and drop, similar to how it's done in sections.

[MWedl]

We are aware of this limitation. Unfortunately this is a limitation of the data structures used to store the field definitions and is not easy to change.

Currently object property definitions are stored in a dictionary of { property1: { type: "string", ... }, property2: {...} }. The problem is that dictionary items do not define an order. The ideal solution would be to store object property definitions as a list with the field ID as property: [ { id: "property1", type: "string", ...}, { id: "property2", ... } ].

This data structure was an design choice very early in the implementation process. Later we encountered some limitations of this choice. We have not changed the data structure yet, because it requires rewriting many parts of the application, affects parts of the core logic and also introduces breaking changes to the REST API. However, we should definitely need to update the data structure.

[dnbsd]

Sorry, if I'm coming on too strong, considering I haven't touched Python for quite some time, or read sysreptor's code.

Wouldn't that be almost automatically solved by OrderedDict? Furthemore, according to the documentation, since Python 3.7, the order of keys is guaranteed to follow the order of their insertion to the dictionary, so pretty much behaving as OrderedDict.

As for backward compatibility. Perhaps adding a new type "ordered object" would not cause breaking changes?

[MWedl]

Unfortunately it's not that simple. In the API (implemented in Python), dictionaries preserve their order. In the frontend (implemented in JavaScript), the order is not preserved.

Introducing an ordered object type would solve the problem, but IMO this would be a hacky workaround around the root cause of the problem. Field ordering is not the only limitation of the dictionary-based data structure (other problem: field ID collisions while editing IDs in the frontend causes glitches). When we solve this problem, we should eliminate the root cause.