To allow app-developers (especially Udir) to show a custom receipt also in cases where they enable autoDeleteOnProcessEnd we need to add the customReceipt component to the receipt container in app-frontend.
Conclusion after a loong time of discussion
However, since autoDeleteOnProcessEnd: true is a feature that in theory should delete (or at least act as if the user believes that the data is deleted) all data after the form is submitted, app-frontend should not have access to the layouts which means that it should not be possible to have a custom receipt if the form has enabled autoDeleteOnProcessEnd. This is a feature we must support since some TE, NSM by instance, is very reliant on having the all data deleted after a form is submitted.
New Proposed Solution
To be able to allow both scenarios we should introduce a way of putting a timer on the auto deletion. This can be done with different approaches, but currently the following are considered:
Adding a new flag in applicationMetadata.json which stores information on how long the data from the form should be stored after the form is submitted. This flag can only be used (or will only have effect) in conjunction with the autoDeleteOnProcessEnd flag. Example:
Adding more legal values to the autoDeleteOnProcessEnd flag, such as a timestamp or a time duration. Example:
"autoDeleteOnProcessEnd": "2h",
"autoDeleteOnProcessEnd": "2023-03-30T05:50:06",
Timestamp may be weird since forms are submitted over a long time intervall, but might be relevant in some cases?
Update
Since it will be ambiguous and contradictory to delay an auto deletion on process-end, we should introduce a new concept providing the app with a timeUntilAutoDelete or timeUntilDelete flag that can be set while having autoDeleteOnProcessEnd: false. This will however introduce a new degree of complexity on Storage since it will need a new component that will do some sort of monitoring of the remaining lifetime for all apps, or add them to a queue when they are ready for deletion.
**Needs more
Additional considerations
If going for option two, or something similar, we should consider to change the name since it is not really deleted on processEnd anymore. NB: Would be a breaking change! ⚠️
Description
To allow app-developers (especially Udir) to show a custom receipt also in cases where they enable
autoDeleteOnProcessEnd
we need to add the customReceipt component to the receipt container in app-frontend.Conclusion after a loong time of discussion
However, since
autoDeleteOnProcessEnd: true
is a feature that in theory should delete (or at least act as if the user believes that the data is deleted) all data after the form is submitted, app-frontend should not have access to the layouts which means that it should not be possible to have a custom receipt if the form has enabledautoDeleteOnProcessEnd
. This is a feature we must support since some TE, NSM by instance, is very reliant on having the all data deleted after a form is submitted.New Proposed Solution
To be able to allow both scenarios we should introduce a way of putting a timer on the auto deletion. This can be done with different approaches, but currently the following are considered:
Adding a new flag in
applicationMetadata.json
which stores information on how long the data from the form should be stored after the form is submitted. This flag can only be used (or will only have effect) in conjunction with theautoDeleteOnProcessEnd
flag. Example:Adding more legal values to the
autoDeleteOnProcessEnd
flag, such as a timestamp or a time duration. Example:Timestamp may be weird since forms are submitted over a long time intervall, but might be relevant in some cases?
Update
Since it will be ambiguous and contradictory to delay an auto deletion on process-end, we should introduce a new concept providing the app with a
timeUntilAutoDelete
ortimeUntilDelete
flag that can be set while havingautoDeleteOnProcessEnd: false
. This will however introduce a new degree of complexity on Storage since it will need a new component that will do some sort of monitoring of the remaining lifetime for all apps, or add them to a queue when they are ready for deletion.**Needs more
Additional considerations
If going for option two, or something similar, we should consider to change the name since it is not really deleted on
processEnd
anymore. NB: Would be a breaking change! ⚠️