Core and all Source plugins should consider field sequences

Still, not having a clear sequence at all is even something that i consider a bug.

Here's my fancy real crazy idea ;-)
Pseudo-Form-Approach
We render the entity form and use element_children to traverse it.
Then, if we find a form element that we can map to a field, we know the sequence.
Problem: I don't know if we can map them reliable here...

Pseudo-Render-Approach
We Create an entity with some special values, trigger rendering (e.g. also with tweaked field theme functions...) and then check in the output where things went.
Problem: Well, even more crazy

Pseudo-View-Mode-Approach
Introduce a special view mode.
Ask the developer to enable this view mode to define the field sequence.
Add a note to the view mode that developers shall NOT use any grouping mechanism.
These weights we can use reliable.

The last one seems feasible to me. Minimum-intrusive as the view modes need to be enabled per content type. Although they're helpers only.

Assigning to blueminds as it is a fundamental bug / limit of the core now.

Gengo defined this a critical problem of their customers. However now that i understand - we have grouped jobs on their side... I'm confused as things are one single job per data item anyway - do they support weighting accross grouping? ;-) *confused*

So we try to order by weight... no own view mode reqired as long as no recursive fancyness applies.

Then we can decide if we try to implement the special cases in recursion...
Or if we support a view mode as a helper if weighted sort (due to grouping) goes wrong. Then, manual interaction required.

We can also flatten / unflatten weight by flatten the data like the OID in X.500 Schemas with the IANA registry, used for LDAP and SNMP:
1.3.6.1.4.1.24535 - Which is the global identifier for our company MD Systems. ;-)
(The structure is left-to-right hierarchical.)

We are about to introduce multilingual paragraphs support.
#2462263: Support paragraphs translation.

Even more it is important that the fields and their values are guaranteed to be displayed in the proper order.

Unassigning.

What is the status of this?

I think we should order the fields if possibly by the default form (display) mode.

Seen again strangely odd sequenced fields such as title field last.

Some thoughts.

1. +++ b/src/Form/JobItemForm.php
   @@ -25,6 +25,11 @@ use Drupal\Core\Render\Element;
   +  const WEIGHT = 1000;
   
   @@ -112,6 +127,9 @@ class JobItemForm extends TmgmtFormBase {
   +          $form['review'][$key]['#weight'] = $content->getComponent($key)['weight'] ?: $default_weight++;
   

   Not sure about this 1000+ strategy.

   I would have expected to more define to start with the elements in the sequence of the form display and append the remaining ones?

2. +++ b/src/Form/JobItemForm.php
   @@ -112,6 +127,9 @@ class JobItemForm extends TmgmtFormBase {
   +        if ($key !== 'title') {
   

   Why do we need a special case for title?
   Title is also a field that is managed in manage form display weight.

I think the best is if you write a test that has a bunch of elements...
Then add the item, check the sequence.
Then change sequence.
Readd and recheck.

+++ b/src/Form/JobItemForm.php
@@ -25,6 +25,11 @@ use Drupal\Core\Render\Element;
@@ -105,6 +110,16 @@ class JobItemForm extends TmgmtFormBase {

@@ -105,6 +110,16 @@ class JobItemForm extends TmgmtFormBase {
+    /** @var \Drupal\Core\Entity\Display\EntityFormDisplayInterface $content */
...
+      ->load($item->getItemType() . '.' . $entity->bundle() . '.' . 'default');

Now you are changing the sequence when showing the form.

Instead you should fix the sequence when addint the item + fields to the job!

Also the code is specific to the source. This lookup does not work for locale and other sources!

Any translator should receive the items in the correct sequence. Not just our form...

In this case we have to reset job item data before every translation request.

Unsure. On one hand i would say this change could require that the item needs to be dropped / readded to the job. Fine.
But this could be an indicator that the field sequence wouldn't change until a manual cache clear is triggered? Please test and fix - or confirm it's just a test issue (thus reset workarounds are fine).

Switching back. Please check input from Berdir.

I tested this manually with a content type from tmgmt_demo and added a third field.
It was first after the body and later between title and body to do a second test run and compare changes.

The job item review form displayed the proper sequence.

The local / drupal user translator displayed the sequence reliably INVERSE.

Found in LocalTaskItemForm

    // Need to keep the first hierarchy. So flatten must take place inside
    // of the foreach loop.
    $zebra = 'even';
    // Reverse the order to get the correct order.
    foreach (array_reverse(Element::children($data)) as $key) {
      $flattened = \Drupal::service('tmgmt.data')->flatten($data[$key], $key);
      $form['translation'][$key] = $this->formElement($flattened, $task_item, $zebra);
    }

No idea why it thinks it needs to reverse the order "to get the correct order"...

Works perfectly after removing the array_reverse().