error corrections components layouts

[paulgirard]

Solving errors needs a lot of components :

• errors summary by columns
• list of groups of common errors on different rows
• explore rows where those errors were spotted
• one modification component by error group
• revalidation action either on the group error or globally we haven't decided this yet

We need to discuss a layout to organise all those information and actions.

[paulgirard]

Here is one first proposition of layout.
It's nt very convincing i have to say... And I didn't include the modification component.
To be discussed

[robindemourat]

Here is an outcome of our discussion about the different components needed to review errors :

All the error resolutions would fit in the same 3-parts layout :

1. One component explaining what the error is
2. One component displaying the context of the error (table excerpt with outline of the faulty cells)
3. One component for solving

We have two different possible workflows in mind :

1. errors are displayed in a table, each row has a "fix" button in end of line - clicking on the "fix" button expands the row so that it hosts the error resolution component described above
2. errors are displayed in a table, each row has a "fix" button in end of line - clicking on the "fix" button leads to a second sub-view with prev-next buttons

In the two cases the components to provide would be as following (tbc) :

• Errors table
• Error expanded explanation
• Error Context (table of excerpts)
• Error formating input (tbd for each type of error)
• Foreignkey error solving

The Foreignkey error solving component would be made of three parts :

1. A proposition of possible correct values based on a Leveinstein on the provided value
2. A select of all existing possible linked items (would it need a preview ?)
3. A button for creating a new item, spawning a schema-generated form aimed at adding the entity

In the case of creating a new item, the NewItem component should be able to recursively display the ForeignKey subcomponents 2 & 3 for choosing of creating items in a third table.

There is also the problem of the fixing order. We recommend the following :

1. provide on top of the todolist the format errors (excluding foreignkey-related fields because their format errors should be fixed through a foreignKey component)
2. then provide non-dependent foreignKeys
3. then the more complex foreignKeys

Does it make sense ?

[paulgirard]

layout

yes that's a good proposition ! About the next/prev or nested in the table approaches, both are fine with me. I would follow your technical/design preferences.

errors list sort strategy

I do agree :

• first format/enums errors
• one level foreign keys (spegen_expimp, sources..)
• complex foreign keys (RICentities & currencies)

Actually We could structure the list as follows :

• format/enums errors all mixed sorted by number of rows impacted (or let the user sort)
• expimp_spegen foreign keys
• source foreign keys
• RICentities foreign keys : reporting and partners columns mixed ?
• currencies foreign keys

foreign key solving component

Yes that's right.
I rewrite the description with my own words.

1. why not including automatic propositions based on some NLP. To define by drafting on takoyaki + talisman
2. select with autocomplete to pick up one choice among the existing ones
3. fallback solution no existing solutions match what we need => extra form + recursive FK validation

If there is no more question/remarks about this last point I'll move it to the dedicated issue.