search

Altinn / altinn-studio

Next generation open source Altinn platform and applications.
https://docs.altinn.studio
BSD 3-Clause "New" or "Revised" License
109 stars 73 forks source link

Improve dataType selection for custom receipt #12905

Open standeren opened 1 month ago

standeren commented 1 month ago

Description

Today there is unfortunately a requirement having a dataType for the custom receipt in the layout-sets file for a custom receipt. This is unfortunate because there is not always the case that an app-developer wants to connect any data to the custom receipt. Because of this we should make it easier for the app-developer to take an active choice to add a dataType only if they need it.

This is sort of a three-sided issue where we can consider different aspects:

1. Default connected dataType behind the scene To make it easier for the app-developer to understand that the data model connection is not required unless they are going to use specific data from a specific data model, we could connect the receipt to a datatype by default in the layout-sets-file and visualize the filed in the config panel as a "legg til datamodell" button that will change the connection. There is an issue with this tho: Until we are supporting multiple data models, the app developer will get the possibility to connect components to data fields from a model even though he/she have seemingly not connected a data model to the layoutset. So an alternative could be to show a default selected data type and include some information on what this connection implies and when you should consider changing it.

2. Information and handling of scenarios when the custom receipt ends up without a valid data type connected. This is a continuation of the point above. We will need some sort of information anyway on what it means to add/edit this data type. And especially what will be the consequence of deleting the connection or the data model. And should the consequence of it always be shown or only be shown if the connection is invalid?

3. What data types should be possible to select? ~Finally we need to consider what models to list as selectable. It is only valid to connect a data type that has been referred to by a previous task. So the most correct thing for Studio to do is to show only the used data models. But on the other side we cannot and should not assume what order app-developers develop in. Maybe they wish to build the custom receipt first before setting up the rest of the process? Then they would not be able to select any data model. And how should we validate if the config is still valid when other tasks are being changed? So maybe it is best to list all and simply inform them, as mentioned in point 2, that it is only valid to refer to a data model used in previous task~ EDIT: We decided to allow the user to "make mistakes" and list all available datamodels

nkylstad commented 3 weeks ago

For point 1: Can we test just adding either a "dummy" (non-existant) datatype, or empty string, in layoutsets config? This seems to work in preview.

standeren commented 3 weeks ago

After gathering some insights from Team Apps it looks like we cannot set the dataType to an empty string. So we should either

  1. try to find a way to add an actual model, but not showing this to the user without making it confusing that it is connected without any active choice from the app-dev. Or
  2. Connect an actual model and show to the user that the receipt has already been connected to a model and inform them why it is connected to this one (it needs a default) and why they could consider changing it if they need to. Or
  3. Leave it as it is today and add information
Ildest commented 5 days ago

Preliminary micro text suggestion

Not certain I have understood this correctly @standeren, but if the text required is in numbered item 2 in the latest comment above, I would suggest:

"Kvitteringen din er knyttet til datamodellen [variabel for datamodellnavnet, hvis mulig] som standard. Du kan velge å bruke en annen datamodell sammen med denne kvitteringen."

standeren commented 5 days ago

This is a good start 🤩 But I think we also need som information on why the user would want to change. Or why it is connected to the default model. We could perhaps add some more to the sentence; ... denne kvitteringen dersom du trenger å vise data i kvittering som **ikke** kan hentes fra den gitte datamodellen.

If we are adding this it might not be so relevant for the app-dev why the current datamodel is connected and why they cannot disconnect it, or? If we on the other hand would inform the user about this as well, we could add some more to the first part of the sentence; Kvitteringen din er knyttet til datamodellen [variabel for datamodellnavnet, hvis mulig] som standard fordi det er påkrevd å ha en datamodell knyttet til kvitteringen. Du kan...

@Ildest

Ildest commented 5 days ago

Yes @standeren, the last sentence is a good suggestion. I would just amend it a little bit:

Kvitteringen din er knyttet til datamodellen [variabel for datamodellnavnet, hvis mulig] som standard, fordi det alltid må være en datamodell knyttet til kvitteringen. Du kan...