Today app-frontend does a check upon instantiation of an app that the current user is a valid partyType to access the form.
However, Studios PreviewController replies only with a static current user which is a PartyType = Person. If any app has set person: false in partyTypesAllowed in appmetadata, they will not be able to star the form.
Currently we have bypassed this issue by mocking all the values to be false in appMetadata so that all partyTypes are allowed. This is possible since there is a special check for this case in app-frontend before the validation of the actual parties happens.
If we were to remove this "hack" app-frontend would pursue to a more detailed check if any of the partyTypes other than person is set to true. Then one special condition partyTypeFilters[party.partyTypeName] will break in Studio due to Studio previewController is responding to the availableParties ([Route("api/v1/parties")]) with only one party which is a person. This list can simply be expanded to include the remaining partyTypes.
But if setting person: false in partyTypesAllowed in appmetadata, the current user will not be identified as a valid party. In order to support this for all apps, the currentUser has to be set dynamically depending on the partyTypesAllowed in appmetadata - it has to be one of those that are set to true.
On the other hand, allowing an even better userExperience, would be to implement a way for the app-developer to simulate their preferred current user. Then they could test the view of their form based on the different partyTypes.
But last point here is probably something to consider for a future implementetion? @UX @Annikenkbrathen
Description
Today app-frontend does a check upon instantiation of an app that the current user is a valid partyType to access the form.
However, Studios PreviewController replies only with a static current user which is a
PartyType = Person. If any app has setperson: falseinpartyTypesAllowedin appmetadata, they will not be able to star the form.Currently we have bypassed this issue by mocking all the values to be
falsein appMetadata so that all partyTypes are allowed. This is possible since there is a special check for this case in app-frontend before the validation of the actual parties happens.If we were to remove this "hack" app-frontend would pursue to a more detailed check if any of the partyTypes other than
personis set totrue. Then one special conditionpartyTypeFilters[party.partyTypeName]will break in Studio due to Studio previewController is responding to the availableParties ([Route("api/v1/parties")]) with only one party which is a person. This list can simply be expanded to include the remaining partyTypes.But if setting
person: falseinpartyTypesAllowedin appmetadata, the current user will not be identified as a valid party. In order to support this for all apps, the currentUser has to be set dynamically depending on thepartyTypesAllowedin appmetadata - it has to be one of those that are set totrue.On the other hand, allowing an even better userExperience, would be to implement a way for the app-developer to simulate their preferred current user. Then they could test the view of their form based on the different partyTypes.
But last point here is probably something to consider for a future implementetion? @UX @Annikenkbrathen
Additional Information
No response
Tasks
No response
Acceptance Criterias
No response