Version Lock-Data Upload
I have module dimensioned by Line items, region, Employee, Version and time. Its an input module for the end user to update the Employee cost for employees by region and by time and version.
I have set a Dynamic Cell Access for read and write of the above module which locks the version based on the admin's boolean selection. Example, If the Admin unchecks, Version 2 would be locked for edit.
I have also create a predefined action for the end user to upload the data using CSV file upload, however when the user uploads the data using the action, they are able to update the values for version which is even LOCKED. How's the user able to override it with nothing of that sort being set up.
I want the user to only be able to upload values to the version thats open for edit.
PS: - This functionality works otherwise, that is, user is not able to edit the data at a module/dashboard level. Its only the upload action thats overriding the DCA.
Hi @Sachinsourav02 ,
I'm not 100% sure now, but thought that items that are locked by DCA could be updated only be updated with an import if the user is Workspace Admin.
But if a regular user can still do it then I presume your option is to build a sub-load module / process. Basically copy the existing module and change the import to first import data in the sub-load module. Then create a saved view that is filtered by your DCA access drivers, and import the data in the original module. This way you will make sure that the data for only the editable cells will be uploaded.
P.S. Noticed that you wrote you have both Region and Employee list as dimensions, and just wanted to check if that's the optimal set up. Could you have 1 employee have data in multiple regions? Or is one employee unique to a region? If the latter is true then you could just map employees to regions in a systems module.
I am not sure whether import will stop based on DCA applied to cell. I am assuming here that users are uploading the file with the version that is also locked(on DCA).
Can you try creating a scenario based import based on version, applying filter to the module that you are uploading as CSV.
Yeah thats correct.
Users are able to load data into versions which are locked.
I've tried creating saved views with version filter, however im using "ask each time for import" for version so that users can decide which version to update, hence in that all versions are displayed instead of filtered version0
Yes a regular user can still override the DCA thats set up.
My query is how come the DCA that works fine on Dashboard level is going off when data is being load.
And yes employee and region have multiple data hence cant do away with that as well.0
Yes, that is also possible solution "ask each time for import".
but I think filtered versions in module would be more robust as users dont have to select everytime.
@Sachinsourav02 This happens when a WSA user imports csv file or full access user , I would suggest not to apply DCA on versions rather use native functionality of edit to lock the cells0
Could you please elaborate0
But like i mentioned i have around 5 dimensions. Currently EMP, REG, LINEITEMS are row headers. Time is column. Version is page selector, this is the template. So i have no other option than to go with ask each time for import.
Filtering version by module will not work with the above ask each time for import.1
@Sachinsourav02 Use native editing functionality of versions which can restrict users to enter the data and see if your import is not impacting the desired version .1
Can you not create a saved view by keeping the time in rows(rest everything in rows) and versions in columns. so that you could apply filter? just for import purpose.
I know you might be thinking on pivot restriction to 3 rows. but I saw a post where more than 3 dimensions are used for pivoting.(i never used though)
@Sachinsourav02 The only possible way to upload data for a "locked" version is only if the Import actions was launched by a user that has "workspace admin" flagged.
The "locked" method is not important: "Edit From/To" from Version settings or DCA. The data for "normal Users" will always be "read-only"
The normal users can launch the import action, they could try to upload in a "locked" Version, the import action will return successful status, but in detailed message you will notice that ALL the cells will be counted in "Ignored" cells and no new data would be updated in the module.
This is not the case for "workspace admin" users: if they will launch the import action, they will be able to overwrite cells that are locked. On import actions, the security is by-passed for workspace admin users ( it is not important how the read-only was managed: by Version settings, by security access or by DCA).
If you will have in the file a column with Version or you will ask an element from the Version list, there will be always the possibility that a user can choose a "locked" Version. If the user will be a "normal user" there is no danger that "locked" data will be updated.
If the "open" version is always only 1 version another way to be sure that the imported data is imported only on the "open" version is to follow these steps:
1. Create a system module without any lists with a text line-item where it can be defined what is the Version "open". The Text needs to show exactly the same Version name.
2. Create action to Delete all elements from numbered list (to delete previous launches data).
3. Import the data file into a numbered list
4. create a module with numbered list + 1 line-item which reference the system module Version
5. Import data from numbered list module using a saved view into the final module. In the final module the data will always update the Version that is defined at point 1.
As you notice, it's a more elaborate solution and has the limit that you can import data only for 1 version at the time. It is also needed an intermediary module where to "park" the data imported by a user.
Also, there is very little chance that 2 users upload a file exactly at the same time. Usually, Anaplan just put on-hold an wait that 1 user finishes an action. Usually I did not have issues with concurrent users, but there is some small chance that this can happen if on the model works a lot of users in the same time.
Hope it helps