Yes, it is tedious to do this, because you’ll have to figure out exactly which services need to have the new ROAdmins ACL and which ones should keep the existing Administrators ACL. The ways to figure that out are either by trial and error (e.g., move something that you suspect is needed and see what works) or by reading the usage logs to see what services are invoked when you perform particular tasks.
BTW, I forgot to say in my earlier posting but you’d have to do the same thing with the ACLs on the DSPs, so that ROAdmins have access to the services they need. And any services used by the DSPs intended for the read-only administrators need to have the ROAdmins ACL also.
I’m not claiming this is easy… just that it can be done if it’s important to you.
Yes, this can be done in 4.6 using the same technique. Putting an out-of-the-box capability on the wish list would be a good idea. However, the hard part is figuring out what to include out-of-the-box. One organization might want the read-only capability as discussed in this thread, while another organization might want to subdivide the Administrator into parts like password administrator, port administrator, account administrator, etc. It might be worth thinking about a reasonable division before you wish for it…
I’ll point out that the exact same problem exists in UNIX operating systems… it’s theoretically possible to subdivide root so you have on administrator who can add users, another who can add printers, a third who can change passwords, etc., but it’s rarely done in practice, at least not without third party products.
#Integration-Server-and-ESB#webMethods-General#webMethods