Data Security Risk? Dashboard Menu Option - Edit - Delete
Hi, I notice that when publishing a module view to dashboard, the 'Edit - Delete' option is by default enabled under the 'Menu Option'. However, this will enable the end users to delete a list member if they have 'write' access to the list. Is it a huge data security risk to everyone?
Now with it enabled to all my dashboard, is there an easy way to disable it (mass instead of individually)?
Only if it is a production list items can be deleted rest all are secured in deployed mode. One thing to note however is that we don’t have to give end users access to lists unless and until there is a need to create items in the list in production environment which can be controlled from Users->Roles-Lists.
And To answer your question there is no mass functionality which can disable it all at once
Re: Data Security Risk? Dashboard Menu Option - Edit - Delete
Thank you for your reply, Misbah. As you said, only production list is exposed here. But production list is used for many cases - one good example is 'Product Hierarchy', which is most commonly set up as Production List. And 'Write Access' is also commonly given to users as they need to forecast on. Same can be said for 'Business Division' as another example of production list. So for a dashboard where users forecast their sales volume by Product/Division, I don't see you can get away from giving them 'write' access to both lists.
Unfortunately we have many dashboards like this built throughout the years ever since the commission of Anaplan, and no integration partners have mentioned this security risk, or disabled the feature on any of the dashboards. If there's no way to disable it on mass-basis, at least Anaplan should make this option 'unchecked' as default. Does it make sense?
Product Hierarchy or any other hierarchy should not be updated by end user and is usually an admin job. But if your end users are adding items to the list from the dashboard then yes Write Access needs to be given and if it is just to input the data for any future period then write access to the lists need not be given. They can still input the data by having write access to the modules and no access to lists.
Personally I always keep this option disabled for end users.
It is a bit of a misconception that you users to enter data in a module they need write access to the list.
They don't. Access to the module will suffice
One only needs to grant write access to a role if that role needs to add, amend or delete members from the list
So as @Misbah correctly stated, in most cases (and especially if being sourced from a data hub), it is best practice not to give roles access to the list. Not only does this reduce the risk of "accidental" corruption, but it is also more efficient as the system doesn't need to pre-allocate memory for the next block of "inserts" on the list
The exception is, of course, if adding items is a part of the user/role process (e.g, promotional, scenario or project planning)
Thank you so much for your replies. Guess I was confused by 'List Access' and 'Selective List Access'. To your points, end users can be granted 'write' selective access on the 'Users' console, but no access on the 'Roles + Lists' console. That solves our issue.