Form and appeal roles

[Joshua-Lakusta]

As a user i want to have limitations applied that are more specific to my role or client type

Acceptance Criteria

Basic

• Create 4 roles for each of appeals and forms
• The roles should be able to be applied to both ministry groups and clients
• This should expand the basic framework to allow for updated roles and permissions moving forward
• These new roles will apply to each individual form and appeal

Appeal Roles

• Form approve/deny
• see form or ability to access the submitted appeal
• View appeal in history
• View decision history
• Approve form final submit decision

Form Roles

• Form Approve/Deny
• See form or ability to access the submitted form
• View forms in history
• View decision history
• Approve form final submit decision

Historical appeals and forms

• All currently designed forms and appeals will follow this behavior

  • All ministry roles will be able to see history list items for both appeals and forms
  • Only the currently allowed groups can see the form submission
  • Only the currently allowed groups can approve/deny
  • Only the currently allowed groups can see the decision history
  • All users that can currently approve/deny can do the final submit decision

• Institution client behavior

  • Can see history list item for all forms and appeals
  • No form access (this is a change from previous state)
  • Cannot approve/deny
  • Cannot see the decision history
  • Cannot do the final submit decision

• Creation of the final note is still linked to the approve and deny

[andrewsignori-aot]

To achieve the roles proposed by the business, the below sufixes would be created:

• view-form-submitted-data
• view-form-history-list
• assess-item-decision
• assess-final-decision
• view-decision-history

Based on the above list, Keycloak roles would be created for each form-definition, as the examples below.

• roomandboardcostsappeal
  • forms.roomandboardcostsappeal.view-form-submitted-data
  • forms.roomandboardcostsappeal.view-form-history-list
  • forms.roomandboardcostsappeal.assess-item-decision
  • forms.roomandboardcostsappeal.assess-final-decision
  • forms.roomandboardcostsappeal.view-decision-history
• stepparentwaiverappeal
  • forms.stepparentwaiverappeal.view-form-submitted-data
  • forms.stepparentwaiverappeal.view-form-history-list
  • forms.stepparentwaiverappeal.assess-item-decision
  • forms.stepparentwaiverappeal.assess-final-decision
  • forms.stepparentwaiverappeal.view-decision-history

The forms. prefix allows easy identification of forms related roles, which, in conjunction with the ".", allow easy extraction of the form-definition name.

[andrewsignori-aot]

@Joshua-Lakusta can we have new ACs to be clear about the behavior of the Pending appeals and Forms, and also in the application's assessment history?
@ninosamson @CarlyCotton FYI

Pending Appeals/Forms

• Should we list the items to users who do not have the ability to approve them?
• Should we list all the items always and have the "View" button disabled?
• Should we allow the user to navigate to the page but display a banner with the information that the user does not have access to the form?

Application's Assessment History