Best Practices: Implementations: Blocking Access by Non-Admins
When implementing upgrades or changes in Archer, what are best practices for blocking access by users who are not system administrators? In other words, when making changes to applications or questionnaires, what are viable options for ensuring that users cannot access the system while changes are being made?
- Community Thread
- Forum Thread
- RSA Archer
- RSA Archer Suite
We use security parameters to 'lockout' users when migrating packages to applications, esecially workflow. General User parameter gets updated to remove access at appointed time then edite again to restore access. Admins/tech team are assigned a different security parameter so access is not removed. A third parameter is assigned to various IDs used by datafeeds.
I agree with Louis. Modifications to the impacted roles to remove end users' access while upgrades/changes are going on are the most effective way to handle it, as it allows you to completely hide an application to everyone. Tough part is making sure you document every single thing you change in your access roles, so that you can set them back when you're done.
Managing role seeings would work too, I don't like changing roles unless have to though. They could be part of package also which would then get modified during install.