By using this website, you agree to our Terms of Use (click here)
Good Morning Everyone,
Today I'm looking at the site map and reviewing how it works with security roles. I understand that within security roles I can revoke, grant, etc on target screen. I created a new dashboard option at the top level. It is the "IC Dashboards" in the screenshot. It appears that by default, users are given access to this new section. This would indicate that every time I add a new item to the sitemap that does not inherit from a parent, I would be forced to change roles to grant or revoke. I kind of support the Linux approach, which is stuff locks by default until access is granted. Is this expected? Is there a setting that dictates default behavior? Thanks in advance for any guidance.
I agree with you, it should be revoked by default.
But I have noticed the same behavior as you with ANY Site Map entry, not just Dashboards. You have to assign some kind of security permission to at least one User Role. If you leave "Not Set" in all of the User Roles, then it will be available to everyone.
Hi Tim,
Thanks again for the information. I realized some default open security had to be taking place, otherwise you would lock yourself out immediately. Thanks again.
This really should be fixed. I created an idea that you can vote on:
https://feedback.acumatica.com/ideas/ACU-I-2456
Personally i think it's ok the way it is. For example, we had a big upgrade earlier this year implemented by our partner. During that upgrade, new screens were added. All of these screens were initially viewable by all. This allowed us to easily review the new functions and then apply appropriate security roles to secure them as needed.
It also means users can publish ARM reports themselves without asking IT (me) to configure security for them. Much better than them publishing a report and then not seeing it on the menu at all.
Once you understand that any Site Map item that hasn't been explicitly secured is globally accessible you adapt as needed.
It's really only a trap for new players.
It is the reverse of what you typically find in tech products. In many products it is very limited by default and you open things up to whomever needs them. Either scenario is functional if the admin knows how to control the software. The reason tech usually chooses the more secure route is because the "oops" are noticed when an individual has a viable need to access a resource and lets you know that they can not access the resource. The default open results in a "oops" an employee is now upset because of sensitive information that they were not suppose to see was open. Or oops a bunch of sensitive information was exposed. That is the difference.
I think Acumatica went this route, not because it was the typical route (its not), but they did not want to immediately upset customers who did not know how to effectively implement security roles. In the event, information was exposed, you can always rebuttal to set the application correctly then and grab a consultant if you can not. Versus, a new customer that is getting upset before commitment because they cant access anything and do not know how to set it and decide to walk away from the product.
Just my guess. I think the site map security roles needs some enhancements in any case. i.e. a select all button, so that you are not going field by field by field...
Royce,
Regarding ARM reports, I hadn't thought about that. Maybe there could be a setting in the General Ledger Preferences screen for a Default User Role for any new ARM reports. Then you could setup a User Role for ARM report creators and make that the default for any new ARM reports.
Online Members
