Project activity #35403
open
Project activity #35009: Documentvertrouwelijkheid & status kunnen bewerken
Ik wil een behaviour hebben die op basis van status definitief een lock zet
0%
Description
Ik wil een behaviour hebben die op basis van status definitief een lock zet op de document zodat deze niet meer te bewerken is
Zie ook ticket #35049
definitief - (Definitief) Informatieobject door bevoegd iets of iemand vastgesteld dan wel ontvangen.
- Owner weghalen
- Tezza functionaliteit: Read only
- Alfresco default API: https://api-explorer.alfresco.com/api-explorer/#/nodes/lockNode
{
"type": "FULL",
"lifetime": "PERSISTENT"
}
Updated by Bram Geerlings about 1 month ago
- Status changed from Backlog to In Progress
Verwerkt in tezza-services 3.3.2-SNAPSHOT. Deze is toegevoegd aan tezza-workspace en klaar om te testen.
Updated by Bram Geerlings about 1 month ago
- Status changed from In Progress to Ready in Dev
Updated by Bram Geerlings about 1 month ago
Node lock wordt gezet via de lockService (dit is een Alfresco service). Deze wordt direct op de node gezet. Wanneer er geen lifetime wordt meegegeven is deze default 'persistent'. Extra controle benodigd om te controleren wie de lock-owner is.
Belangrijk: De lock is alleen te zien in Share. Tezza UI toont dit (nog) niet.
Updated by Bram Geerlings about 1 month ago
- Assignee changed from Bram Geerlings to Maaike Bommerson
@Maaike Bommerson , kun jij dit testen/accepteren icm met de frontend? Graag bevindingen of acceptatie melden in de ticket en terugzetten op mijn naam zodat ik een release kan maken.
Updated by Maaike Bommerson about 1 month ago
- Assignee changed from Maaike Bommerson to Bram Geerlings
Besproken met Tahir:
Het zetten van status definitief moet er voor zorgen dat het document niet bewerkt mag worden, dus ook offline bewerken
Updated by Bram Geerlings about 1 month ago
- Status changed from Ready in Dev to Feedback
- Assignee changed from Bram Geerlings to Tahir Malik
Na gesprek met Maaike:
Offline bewerken was al niet meer mogelijk, maar ook eigenlijk niet het gehele probleem.
Bij het zetten van een lock behoudt de owner bepaalde rechten. Dit kan worden opgelost door het zetten van een lock als admin te doen waardoor alleen de admin nog toegang heeft tot het document.
Probleem met een lock is dat de zaak niet meer te archiveren is. Dit zou via tezza-rm kunnen worden opgelost door locks te verwijderen tijdens het archiveren, als het document status 'definitief' heeft.
Een andere optie is inherit permissions uit te zetten op het document, de huidige permissions om te zetten naar 'consumer' en de owner van het document 'admin' of een service account te maken.
Hier komt nog een probleem bij om de hoek kijken dat is opgemerkt door Maaike: Bij het wijzigen van het type kan de status worden aangepast.
Staan we dit toe? Dan moet de behaviour worden uitgebreid met de statusverandering vanaf definitief (inherit permissions aan, owner terug naar degene die het document type aanpast etc).
Als we dit niet toestaan (definitief is immers definitief) vergt dit een front-end change om bij documentstatus definitief het veranderen van status (en type) niet meer toe te staan.
Kort samengevat:
- Willen we een lock behouden? -> tezza-rm aanpassen om documenten te unlocken. Kan problematisch zijn voor partijen waar geen gebruik wordt gemaakt van tezza-rm.
- Willen we de permissies aanpassen naar consumer, inheritPermissions:false en owner aanpassen -> Behaviour uitbreiden en keuze maken tussen owner 'admin' of owner 'serviceaccount' (welke service account etc. is dan belangrijk).
- Is het mogelijk om van een definitief document het type aan te passen, en zo ja, is de status dan ook aanpasbaar? -> Frontend change indien niet mogelijk, uitbreiden behaviour indien dit wel kan.
@Tahir Malik , zou jij hier op kunnen antwoorden?
Updated by Bram Geerlings about 1 month ago
Ook overlegd met Rick de Rooij over de volgende aanpak:
Wanneer een document 'definitief' wordt gebeurt het volgende.
- De permissies die uit de zaak worden overerft worden op 'consumer' gezet, op de SiteManager permissies na. Die blijven in staat het document te bewerken.
- InheritPermissions wordt uitgezet op het document zodat de gezette permissies intact blijven
- De owner van het document wordt System
- In RolCreateActionExecuter en RolRemoveActionExecuter wordt logica opgenomen om nieuwe behandelaars toe te voegen op het document of verwijderde behandelaars te verwijderen van het document
Hoe om te gaan met de mogelijkheid om navenant nog steeds het type van het document aan te passen moet nog worden nagedacht. Het opstellen van een extra permissie groep is voorgesteld door Tahir.
Updated by Tahir Malik 4 days ago
- Assignee changed from Tahir Malik to Bram Geerlings
Bram Geerlings wrote:
Ook overlegd met Rick de Rooij over de volgende aanpak:
Wanneer een document 'definitief' wordt gebeurt het volgende.
- De permissies die uit de zaak worden overerft worden op 'consumer' gezet, op de SiteManager permissies na. Die blijven in staat het document te bewerken.
- InheritPermissions wordt uitgezet op het document zodat de gezette permissies intact blijven
- De owner van het document wordt System
- In RolCreateActionExecuter en RolRemoveActionExecuter wordt logica opgenomen om nieuwe behandelaars toe te voegen op het document of verwijderde behandelaars te verwijderen van het document
Hoe om te gaan met de mogelijkheid om navenant nog steeds het type van het document aan te passen moet nog worden nagedacht. Het opstellen van een extra permissie groep is voorgesteld door Tahir.
Akoord!
Gem Haarlem besproken en document moet gewoon voor iedereen Read-Only zijn behalve SiteManager.
Dus iedereen Read-only rechten geven met inherit permissions eraf.
Een gebruiker mag definitieve documenten ook geen meta-data aanpassen.
