At this stage, the goal is to display string fields in the 4 columns layer.

• Display in the Document

  • Implement the grid system

  • A new key is added in Section payload with configured fields (see below)

  • Design configuration in database (see below)

• Display as PDF

• Configuration

  • Introduce the configuration modal

    • Modal should display the generic configuration message

    • Modal only propose String fields

      • Except the fields that correspond to Title semantic or Description semantic (legacy, it used to be possible to choose string fields)

      • User have access to fields of tracker they can access

      • User have access to fields they can read

      • Fields are injected in the app at load (no REST route)

    • Mock-up needed: empty state when no fields can be configured.

  • Add the fields to the PUT /artidoc/:id/configuration payload

JSON example of the Section payload

{
// Artidoc section representation
fields: [
  {
    type: "string",
    label: "Papa Mike",
    // We do not use a "rank" key to know the order, because fields have individual permission levels. We trust the order of the Array of fields.
    display_type: "column", // display_type can be "column" or "block". By default it is "column", which means it will stack in 4 columns layer.
    value: "Alpha Bravo"
  },
] // end fields
}

Schema of the database table for the configuration

item_id // ID of the artidoc document
field_id // ID of the field in tracker_field
rank // relative order of the fields
display_type // "block" or "column"

Introduce specific behaviors:

• When an Artidoc is duplicated, the configuration is duplicated.

• When a field is deleted at tracker level, all Artidocs that render this fields are updated to remove the configured field.

• When the tracker is changed, the configured fields are removed.

• When a Section is updated, the corresponding fields are reloaded.