Skip to content

Review use of "AG Ministry" attribute on organization and consider more flexible solution  #6442

@sheaphillips

Description

@sheaphillips

Describe the issue
A purpose-defined "IsAgMinistry" attribute is used to drive "AG only" behaviour in the registry. Conditional logic in the code depends on this attribute to trigger different UI behaviour as well as different data passed into the provisioner (and behaviour in the provisioner). We should avoid ministry or sector specific behaviour as it is not sustainable for us to support at scale (e.g. any team, ministry, or sector could have expectations of their own specific behaviour). It also creates a dependency between business processes or policy over which we have no control.

As an alternative to implementing this kind of data or behaviour that is specific to a subset of users, we should attempt to understand what the generic/common/abstract need is, and - if deemed generally valuable and feasible by us - implement in a way that can be used by any team/ministry/sector.

In the case of the IsAgMinistry attribute - this was to drive some different UI for AG users when they are creating a new product, and to pass an additionally attribute to the provisioner, so it can handle appropriately (not sure what special things it does for AG).

Rational/Why
We should be providing equivalent functionality / value to all client areas. As it is, we are providing unique capabilities for one area that are not offered to others. This is implemented in a way that is coupling business logic to "magic" data values.

Additional Context

  • Link to the code repositories
  • List of technologies that may be expected to be known in order to work on the task
  • Clear description of where the code change is going, e.g "add the text input to the create request form in components/request.js"
  • Clearly identify which products are being updated ("Platform Services Registry")

Dependencies

  • Internal, external, who to talk to if more information is needed

Tests

Definition of done/Acceptance Criteria

  • Clear description of the intended final result
  • Acceptance criteria that describes the action a User Acceptance Tester would be trying to see if the work is complete

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions