-
Zastupitelnost (delegations) → kazdy user si moze nastavit zastupcu, kto ho bude zastupovat v schvalovani v IDM.
UI Enhancements
This page is a stub, it is a work in progress. |
This document contains notes for designing self-service user interface. Mainly for requirements of Role engineering and maintenance and Role request processes.
Principles and requirements
- Easiest terminology possible
-
Directed for people with near zero knowledge about Identity and access management.
Beware of: Entitlement, Inducement, Assignment, *ment, Archetype, Relation, Delta, Resource and any other terminology created specifically for Midpoint. |
We should start using term "access" for role assignment. It is easily understandable for end-user. The role XYZ:User gives you access to the application XYZ. We should start using "Request access" instead of "Request role".
- Fast and easy
-
People just want to easily and quickly find what they need to do, do it and close IDM. This must be delivered and supported by the design.
- Information must be delivered in business form
-
User should see the data in business form E.g. user history - it should have list what happened to user - user does not need to open each item for searching what has happened, but having view and in each line having datetime of the change and (if possible) field or few fields that was changed and (if possible) it’s value. Of course not for each attribute for user creation.
Midpoint has quite sparse screens - more info on one screen is necessary.
- Opening multiple objects in tabs
-
It is quite common that user is comparing 2 objects. (E.g. manager sets access for his team according one team member. He opens the team member and on the other window, he configures other person.
This is so common operation pattern for end users (copying the data from one object to another), that opening the object in new tab
is a must.
- Delegations
-
TODO: how exactly to handle this. - probably existing way is enough. Need to review.
Self-service components
Self-service section should contain following sections:
-
My profile
-
My passwords
-
My access
-
My roles
-
My approvals
-
My requests
-
My teams
-
My preferences
Self-service details
- My profile
-
Contains user’s attributes. User can modify them based on his/her privileges.
This is password self-service. People do-not understand word credentials
. Password is better.
Main self-service screen for requesting/removing and modification of user’s access.
Here, the user can see w - rozdelenie: ○ business level ○ applications § a pod nimi aj ake roly ich prideluju - moje opravnenia - tu mozem poziadat o novu rolu, ○ mozem aj poziadat o jej odobranie ○ mozem menit atributy jej priradenia - tu by som mal vidiet aj "my requests" - vsetky requesty, ktore som urobil, ich stav (a v detaile aj ich priebeh). - organizations ○ do ktorych organizacnych jednotiek patrim § mozu byt rozne organizacne struktury - tak pre kazdu strukturu nejaky popis. - application access
Users requests - active and historical. Here can user see what is the state of his requests.
These requests should be in view with correct information.
Following chapters:
-
My requests (for me or for somebody else)
-
Request for me
-
maybe also Request for my team or My team requests
History - in separation to my requests or requests for me
-
requesty, ktore som mal - cize co vsetko som robil a bolo nakoniec schvalovane.
-
my requests - tu su requesty, ktore som urobil ja
-
requests for me - tu su requesty, ktore urobil niekto pre mna
-
kvoli performancu zobrazovat najprv requesty za posledne obdobie (mesiac/3 mesiace) a vsetky az po nejakom rozkliknuti.
Mozno toto by nemuselo byt, ale tie requesty by mohli byt dostupne v historii usera … Neviem presne.
List of approval tasks. By default - active tasks, but also history should be available (after some click).
The data should be visible in a table - for fast view and fast approval processing. This is necessary to vyvazit generation of many approvals because each role assignment has
-
Active (tu by malo byt zobrazene, co kto pozaduje v tabulke, aby clovek nemusel otvarat, ak nepotrebuje) ○ Access request: § Date Operation Who What Why .additional info. <Approve><Reject> ○ Role update § podobna tabulka ako vyssie. ○ Other: § sem nejake ine approvaly.
-
History (last 30 days / older) ○ Tu mozem pozerat vsetky approvaly. Viem ich otvorit. Su ale iba read only. § Pri otvoreni sa zobrazi celkovy request aj s worflowom a business informaciami.
This is space for delegated administration, just this is standard user, not IDM administrator. Additionally, team manager may see his subordinate attributes and access of his subordinates.
User with to for people having specific role (e.g. team-access-manager) can modify attributes for the user and his assignments (access).
Optional - advanced: The standard user may see also his team members
Notes:
-
zobrazenie clenov timu - podla roznych organizacnych struktur ○ zobrazit iba ak vediem team, pripadne som v nejakej pozicii administratora teamu
-
moznost vidiet pre toho clena timu a vediet ho editovat ○ vediet mu editovat atributy (note: ziadne schvalovanie tu nebezi) ○ vediet pri roliach: § pridelovat § odoberat § modifikovat atributy ich priradenia ○ <RESET hesla ???> → Toto by bolo fajn, ale neviem isto, ci to je vhodne
-
moznost pridelit cloveka v ramci organizacnej struktury ? ○ tuto by bola moznost pridelit si hocikoho do teamu a zmenit ho. ○ neviem, ci je to dobre. Asi to vytvaranie
-
bude bezny user moct vidiet aj ludi zo svojho timu ? - aby sa vedel pozriet, ake opravnenia potrebuje. ○ tu by ale boli veci iba read-only
- My preferences
-
-
tuto mozno ako by mal mat user zobrazovne veci. Zlepsenie citatelnosti a zrozumitelnosti udajov v GUI.
-
Language: - different people may need different language versions. This may be harder for implementation.
-
Date & time format - Important! Date & time format must be correct - at least the same for whole installation.
-
12/24 hour format
-
Thousands separator
-
Decimal separator
-