User Stories - Other
This document contains user stories that would be implemented, but don’t fit into any of the category
This document will be tuned during summer 2023.
1. Performing actions using buttons
Approval steps in midpoint are initialized by identification of event which is not always intuitive for end user. The main point of starting action is sometimes "hidden in the code" - e.g. modification of role name requires approval of role owner, or moving object in its lifecycle. It is ok, just this is not visible.
It could be good if engineer can have option to provide a button to start some action. This button could e.g. move the object to next step in workflow. For this we have already custom actions for object lists. Just it could be similar custom buttons for objects.
Additionaly (even better for users, but much more complex to implement) this button could open modal window with specific form where user can add some parameters and by saving it would start processing.
This concept could be used in following user stories:
- User story
-
AS a user creating an object in its lifecycle
I WANT to have buttons <SAVE as DRAFT> for saving my modifications but not starting the approval and <SEND TO APPROVAL> for starting the approval of new object.
SO THAT I can prepare object but not start approval directly when I don’t have all information collected. - User story
-
AS a user modifying lifecycle state of the object
I WANT TO see buttons to understand to which lifecycle stage should I move the object
SO THAT I am not confused and see directly what I can do with the object.
Example of workflow stages: Naming is different from our lifecycle states, as the naming can be different - even for different archetypes.
-
New object can be saved in ACTIVE state or in DRAFT. So the user in new object can see <SAVE AS DRAFT> and <ACTIVATE> buttons.
-
Object in DRAFT can be moved only to ACTIVE or DECOMMISIONED stage. So the user can see buttons <ACTIVATE> and <DECOMMISION>
-
Object in ACTIVE state can be moved to INACTIVE or DECOMMISIONED stage. So the user can see buttons <INACTIVATE> and <DECOMMISION>
-
Object in DECOMMISIONED state can’t be moved anywhere, so no buttons is displayed.
2. Synchronization of UI changes to GIT objects
This concept relates to this feature request Align Configuration Management and Version Control
The UI features for providing some configuration (e.g. resource wizard) should help inexperienced engineers to perform configuration easier than via direct XML files modification.
This user story covers whole midpoint configuration - not only approvals. When engineer utilizes UI features for configuration, then he must understand which objects were modified to be able to mimic the configuration in XML files in XML configuration files that are stored in GIT.
This is complicated process and engineer may not know which objects were modified (especially if multiple objects were modified). Additionaly, the objects contains additional operational elements. Inexperienced engineer may not fully understand which elements were added by his configuration and which by midPoint while operations.
- User Story
-
AS an IAM engineer who performed a configuration of midPoint feature via UI,
I WANT TO have a feature in midPoint or in midPoint Studio which helps me to synchronize the modifications to my project files,
SO THAT I can import the modification performed via GUI to my project easily and with full confidence that I didn’t miss any modification.
| Midpoint Studio already provides features for cleanup of existing objects from operational attributes and comparing them with objects already present in repository. It helps skilled engineer and might be used for this, just it will not provide engineer full confidence of which objects were modified byt the operation. |
2.1. Workflow / lifecyle definition
TODO - engineer is able to define workflow using stages and transitions in UI.