Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more!
We miss a full history concept for many Admin Objects, f.e. ACL.
Many Admin objects have a history, but others - especially important ones like ACLs - have not.
History entries of who changed what and when would be very helpful.
This is an extension of Bertram Kroell and his idea of providing a change history for Integrity User & Group Domain.
We reported this already in 2008...
There seems to exist a feature request 79251 that was planned for Integrity 2008, but never got implemented.
We know that this could "somehow" be achieved by enabling audit log, but this is by no means the same.
Are we talking about si ACLs or im ACLs?
To understand the use case better, I am going to ask a few questions - May I know what is the exact use case? Why an administrator would want to know ACL history? To check who changed what and why? How many administrators you typically have for your installations in your org?
I am talking about ALL admin objects.
As said, ACLs (IM and SI) might be the most important ones, but others, like IM configuration properties or IS configuration properties, would also be helpful.
A change history is good if something goes wrong or does not work - then we could see if the admin objects were recently changed and by whom - and also determine the projects affected and the steps that have to be taken.
We normally have only 2..3 admins here, but even with only one admin, it is not always easy to remember the changes done f.e. in the last month.
Evaluating Access rights in Integrity is a mess.
For IM it is almost impossible to understand the dynamic groups concept for the end-user
Also the item type workflow does show a solid line but because of constraints the actual user is not allowed to perform that transition.
In SI it is really critical - even experienced admins have difficulties in understanding what a user is allowed to do or not on this or that project / member. First we need to check for the user specific group memberships, then we need to go through ACL trees to check what group is allowed to do what where and later we need to map this to the real repository folder hierachy and take care for the permission inheritance from any higher ACL level then the spot I'm currently locking at. This is extremly fragile, complex and very easy to fail.
A multi-dimension report for admins is needed to show:
I would be happy to discuss above statements in more details.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.