cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

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! X

Provide Change History for all Admin Objects (ACLs,...)

Provide Change History for all Admin Objects (ACLs,...)

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.

6 Comments
ssaul
15-Moonstone

This is an extension of Bertram Kroell‌‌ and his idea of providing a change history for Integrity User & Group Domain.

ssaul
15-Moonstone

We reported this already in 2008...

There seems to exist a feature request 79251 that was planned for Integrity 2008, but never got implemented.

ssaul
15-Moonstone

We know that this could "somehow" be achieved by enabling audit log, but this is by no means the same.

vichavan
8-Gravel

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?

ssaul
15-Moonstone

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.

BKroell
7-Bedrock

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:

  • Permissions for a user or a group on certain member or project.
  • It shall be possible to drill down on defineable permissions, groups, users as kind of a filter.
  • It needs an option to actually evaluate defineable permission on any level out of the project / sandbox view
  • I want to see all user being able to work on this level (having this or that permission)
  • I want to see what permissions a dedicated user / group as on a certain project / member.
  • I want to see what a user is able to see (projects/members) / do (permissions) in his assigned roles

 

I would be happy to discuss above statements in more details.