Interesting! I didn't know there was a release planned.
I'm keen to check the Filters performance, but I also like the features....Top level list item is going to be particularly handy. I also like the smaller ones : "Open source module" from LIs and Close others option on tabs.
Ahh, that's unfortunate to hear that the new setting won't work with users who have selective access enabled. We would love to have it default to the user's top-most item. This is a step in the right direction but I hope there will be more to come!
In relation to the open source module update, I want to confirm that this will adhere to the access settings set up by role/module. For instance, if a user has a role that doesn't have access to a particular module, they won't be able to open it via drill down, will they?
A note for anyone reading along. Upon thinking about this update more fully, I realized that it does pose some not insignificant security risks to us. Due to the large number of modules (1300+) and roles (20+) in one of our models, we elected to state that all modules should be set to "read" and then updated to "write" or "none" where necessary with the express note that end-users can't get to modules unless they are published to a dashboard. The dynamic is now shifting in that users will be able to get to up-stream modules they weren't able to access before. We have our ledger data coming in on a 2D table - selective access isn't applicable here - and unless we change access to "none", almost all users would be able to access all of the ledger data. We will be making that update, but the trade off is that users won't be able to drill down as effectively as before. I don't believe many non-admin users are drilling down to that level, but we can't rely on "users probably aren't doing it" to secure our data. We will need to be extra vigilant going forward in securing data in modules.
If I remember rightly one of the previous releases introduced a similar issue for us.
We have since added specific governance checks to make sure any new releases would be assessed with this sort of issue in mind eg ensuring users won't be able to access/drill-down to modules/data they shouldn't have access to.
We also have gating points/checks during design/build to ensure the design account for this, together with non-functional test scripts, particularly when a model holds sensitive data.
As far as I'm aware releases are deployed across all workspaces, meaning there is the risk of introduce a risk before it can be tested/mitigated. Is there a different option that should be considered ?
Thanks for looking into the potential risks and trade-offs, it is always very useful to understand the implications of new developments.
It would be great if Anaplan could explain their approach to testing and understanding the risks behind the development of new features and functionality within the product. Also with every development the team at Anaplan makes it would be great if they could highlight what we can expect to change as model builders from the potential risks and release a detailed guide to the new functionality. Otherwise like you say, we are subject to data breaches and without knowing there is a potential risk, this could be damaging many data governance and risk processes.
@KayneSchwarz is this something we can expect to see released alongside the product releases?
I have also suggested this as an idea to the community: