Deactiveren van Person In Role elementen in een PSB

[edelater]

Format voor (intake en afhandeling van) issues GC180508-09

GC / 8 mei 2018

Wat komt er binnen (vraag /opmerking) (uitgangspunt: de vraagsteller is ‘bewust onbekwaam’)

1. Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’): “Als <gebruiker/rol> wil ik zodat ik krijg” Als beheerder wil ik een rol of machtigingsrol (substitute) van een persoon kunnen deactiveren zodat ik:

• een tijdelijke vervanging ongedaan kan maken -- dus dat iemand tijdens een vakantie namens zijn collega mag antwoorden en daarna niet meer

• een persoon/rol die vertrekt zonder opvolging uit kan faseren, -- bijvoorbeeld met een rol vergunningen coordinator die klaar is als alle vergunningen rond zijn, zodat je daarna die transactie ook niet meer kunt kiezen om te starten, want er is geen opvolger. Maar die coordinator moet wel zelf zijn openstaande transacties kunnen afronden door te beantwoorden. Dit is dus alleen nodig voor gevallen waar geen opvolger(successor) komt. In het geval van 5 adviseurs, kan het projectteam dan kiezen of de vertrekkende zelf zijn werk afmaakt(gedeactiveerd), of dat dit door een collega afgehandeld moet worden(successor)

2. Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder) Ed de Later, zie zijn originele beschrijving hieronder: _> Dit issue is onderdeel van een serie issues waar Future Insight tegenaan liep tijdens implementatie van VISI.

substitutions:

• iemand die substitute heeft zelf blijkbaar niet zelf de rol, maar mag alleen handelen 'namens' iemand anders.
• hoe hef je een substitution op? Andere leverancier gebruikt <state />, maar wat kan/moet daarin?_

Arne Bruinse: B&S gebruikt het state veld mbv de waarde "passive" om exact het bovenstaande te bereiken en wil dit graag in de systematiek geimplementeerd zien.

3. Datum en oorsprong van het verzoek* Ed de Later: 6-9-2019 Arne Bruinse 01-01-2004

4. Waarop heeft de vraag betrekking: a. Open Standaard (VISI / COINS)

5. Wat is de urgentie ) ‘M’ (must have; hindert de dagelijkse procesgang/doorgang van een project; moet zo spoedig mogelijk worden opgelost) ‘S’ (should have; hinder kan worden omzeild in dagelijks werk; moet binnen redelijke termijn worden opgelost) ‘C’ (could have; geen directe hinder; kan een keer worden opgepakt) ‘W’ (won’t have, c.q. nice to have; komt nu niet aan bod maar kan in de toekomst, bij een vervolgproject, wellicht mogelijk interessant zijn)

@ArneBruinse : C @edelater : ....?

6. Toelichting op de urgentie* B&S : we gebruiken dit al , zou fijn zijn om het met zijn allen in de standaard te ondersteunen @edelater : ...?

‘Open Standaard’

1. Stel vast of het een ‘bug’ is, of een ‘verbetervoorstel’, of een ‘ander verzoek’
2. Verbetervoorstel a. Maak de userstory expliciet; mogelijk valt die uiteen in meerdere user stories

• Als beheerder van een project wil ik iemand die vertrekt van het project de ruimte geven om zelf zijn acties af te ronden omdat er geen opvolger voor deze persoon komt.
• Als beheerder wil ik een (tijdelijke) machtiging uit kunnen schakelen omdat deze na terugkeer van bijvoorbeeld vakantie niet meer nodig is.

b. Beschrijf de randvoorwaarden (“anything the solution can assume to be true when the use case begins”). c. Completeer de ‘definiton of ‘done’ (“anything that must be true when the use case is complete”).

• Je kunt pir elementen deactiveren, zowel voor normale als machtings pir's
• normaler pir's die gedeactiveerd zijn kunnen geen nieuwe transactie meer starten of ontvangen, maar wel reacties sturen en ontvangen in lopende transacties. @jvgeijlswijk Nog even beter over nadenken de volgende keer: Subtransacties: het lijkt mij dat je dan geen nieuwe subtransacties op die rol mag ontvangen, maar dat je met die rol nog wel nieuwe subtransacties mag starten, mits die benodigd zijn om de transactie af te kunnen ronden? -geblokkeeerde machtigings pir's werken helemaal niet meer -er is een nieuw optioneel element "active" of "locked" oid op het pir element waar middels een boolean kan worden aangegeven middels true/false dat een pir element geblokkeerd is.
• er is een testcase in de certificeringstest toegevoegd om de nieuwe eisen af te kunnen testen
• er is een beschrijving in de systematiek die ook uitlegt dat deze setting geen effect heeft op opgevolgde rollen. @ArneBruinse moet het hieronder een andere keer weer verder gaan uitschrijven d. Beschrijf het verbetervoorstel / of gewenst gedrag (“the set of steps the actors take to accomplish the goal of the use case. A clear description of what the system should do in response to each user action.”) e. Beschrijf de voordelen van de verbetering f. Beschrijf eventuele “Alternate Flows” (“capture the less common user/system interactions, such as being on a new computer and answering a security question). g. Beschrijf eventuele “Exception Flows”
  (“things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password).

4. Ander verzoek a. Beschrijf de vraag zo gedetailleerd mogelijk b. Beschrijf de voordelen van het voldoen aan het verzoek

5. Plaats de gedocumenteerde bug, verbetervoorstel of ander verzoek op de verzamellijst ter prioritering in het kader van de release cyclus (ook op github??)

‘VISI Raamwerk’ of ‘COINS Referentiekader’

1. Stel vast of het een ‘bug’ is of een ‘verbetervoorstel’ in de standaard, of een probleem bij het gebruik van de standaard (bij VISI: het maken van raamwerken; bij COINS: het gebruik van een referentiekader)

2. Indien ‘Bug’ of ‘verbetervoorstel’ voor de Standaard a. Verplaats de vraag naar het bakje ‘Standaard’ en handel daar af conform procedure

3. Indien probleem bij gebruik a. Beschrijf de vraag zo gedetailleerd mogelijk (indien alsnog een probleem met de standaard blijkt: zie 2.) b. Beschrijf de voordelen van het voldoen aan het verzoek c. Plaats op lijst ter afhandeling (door beheerder van de OS, helpdesk of adviseur)

‘Software’

1. Betreft het VISI-software of COINS-software a. Is het een generiek probleem -> zie punt 2 b. Is het een specifiek probleem: informeer (de helpdesk) van de desbetreffende softwareleverancier c. Informeer eventueel de desbetreffende Expertcommissie en Gebruikerscommissie

2. Generiek probleem voor de Standaard a. Verplaats naar het bakje ‘Standaard’ en handel daar af

  P.S. Definition of ‘DONE’ (checklist):

De ‘definition of done’ is de checklist van dingen die gedaan moeten zijn voordat je klaar bent met een issue. Er is een generieke definitie, maar ‘done’ moet goed aansluiten bij de vraag. Het kan dus voorkomen dat er nog specifieke dingen aan moeten worden toegevoegd. Dat moet dan gebeuren voordat het oplossen van de vraag start. • Generieke ‘definition of ‘done’ is helder • Eventuele specifieke dingen die ook moeten zijn gedaan, moeten aan de generieke definition of ‘done’ worden toegevoegd

De check van de oplossing is dan (voor zover relevant): • Alle ‘to do’ items voor de User Story zijn voldaan, inclusief de specifiek toegevoegde dingen. • Relevante gebruikersdocumentatie is gemaakt of aangepast. • Relevante technische documentatie is bijgewerkt en geactualiseerd. • De ‘reporter’ heeft het werk geaccepteerd. • Er is feedback van eindgebruiker(s)/vraagsteller gevraagd/gekregen op het opgeleverde product. • Alle unit- (bouwer), integratie (productowner) functionele (key users) testen zijn succesvol gedraaid. • Indien hiervan afgeweken wordt dan is dit opgenomen in de userstory (afwijkingen opgenomen in userstory).

[ArneBruinse]

voorstel besproken tijdens werksessie voor de vergadering:

• het laatste psb is altijd geldend voor alle communicatie,

• de namespace van het raamwerk is dus niet leidend omdat het psb eigenlijk alle raamwerken van het project ondersteunt.

• dit is nodig omdat er maar 1 lijst qua projectinrichting nodig is. het is onmogelijk dat er per raamwerk allemaal verschillende rollen per persoon te hebben.

• rollen en person in role elementen in het psb waar communicatie in het project op is verzonden mogen daarom niet verwijderd worden uit het laatste psb

• rollen mogen evt WEL verwijderd worden uit een RAAMWERK. ook hierdoor is een psb dus niet altijd te valideren aan het laatste raamwerk.

• door een person in role element de "state" op "passive" te zetten, kan een rol van een persoon, al dan niet als machtiging of opvolging uitgeschakeld worden. In het geval van een machtiging moet dit direct de rechten afnemen. Bij eigen rollen en opvolging betekent dit dat de persoon de lopende transacties wel mag afronden. Er mogen geen nieuwe transactie aan en door die pir gestart worden.