Upgrade from 2.3 to 2.4 Process
For existing customers currently working with UX version 2.3 or earlier the new private views feature requires some manual changes to existing content store configuration in order to work properly. For any new install of 2.4 or later these changes are not needed.
These changes are minor and quick to implement. This guide will walk you through all steps required.
There are 2 basic changes which need to be made:
- At cube security level change the permission of the APQ User group to }ElementAttributes_}APQ UX App from READ to WRITE
- At element security level change permissions for ordinary users to public apps from WRITE to READ (if element security is currently implemented as WRITE by default)
The reason for the required changes is that the repository for screen contents and configuration is the attributes cube of the UX App dimension. In order to be able to edit their own private views users require WRITE access to the attribute cube. However, they must have READ ONLY access to public views. (WRITE access to private views is handled automatically by the application.)
if you have Pulse installed,
you can use this online package , which will automate the entire upgrade process.
make sure to run '}APQ.UX.Security.Dim.App.LoadAccessRights' after package was executed.
In case Pulse is not an option,
you can use the following offline package , but please pay attention as its needs to be done in 2 steps.
Note:
After completing the Content Store update , you can simply use the installer , and update your existing 2.3 webapp , to compete the upgrade process.
Offline package process
Take a backup of the current content store and stop the service.
Copy from the offline package , only the '}APQ.UX.Server.Upgrade.2.4' process.
start the service , and execute the process '}APQ.UX.Server.Upgrade.2.4'.
Copy all the files from the offline package.
start the service , and execute the process '}APQ.UX.Security.Dim.App.LoadAccessRights'.
upgrade to the Content store is now complete.
Note:
The part below , is all covered on the }APQ.UX.Server.Upgrade.2.4 process and can be used as reference to understand the security concept of the private views.
Step 1: Change cube security
Locate the }CubeSecurity cube.
Set cube access to WRITE for the built-in APQ User group.
Setting the security can also be done via the security GUI in Architect.
Step 2: Edit element security for }APQ UX App dimension
Security for all UX screens is managed via regular TM1 element security of the }APQ UX App dimension. An application has been built to assist managing the security. Rather than editing the security directly which requires element-by-element editing a cube is provided for data entry }APQ UX App Security Access. This cube has rules which handle inheritance so that security only needs to be set at app level and automatically inherit to all screens. Security settings are then transferred to the security model via TI process.
Locate the }APQ UX App Security Access cube.
The security level for the APQ User group must be set to maximum of READ not WRITE for all Public Apps (this can include apps under the Admin node which appear as buttons on the top right of screen, not just apps under the Main node which appear in the AppLauncher and AppBar.)
Permission levels for APQ PUser and APQ Admin groups are set automatically.
- APQ PUser: “Power Users” with permissions to author and edit Public Apps
- APQ Admin: “UX Administrator” with permissions to import and export apps between content stores and maintain users and security
Note:
Every user is automatically assigned to the APQ User group which contains the minimum set of permissions to us Apliqo UX. By default Apliqo UX uses the APQ User group for access to apps. However, as access to apps is just normal TM1 element security you are of course free to use other groups for this purpose. This is would necessary, especially in cases where members of different groups should have access to different menus and screens. In this case you should clear (or set to NONE) element security permissions for APQ User and assign permissions to the relevant groups. Just remember that for any “ordinary users” their permission to Public Apps should only ever be READ and not WRITE.
Step 3: Sync permissions to security model
Pushing the element security permissions from }APQ UX App Security Access to the security model is done via the process }APQ.UX.Security.Dim.App.LoadAccessRights.
Run this process to sync security. (This process is also part of the daily maintenance chore)
Open a view in }ElementSecurity_}APQ AX App to check that permissions in the actual security model are consistent with what has been set.
Note:
Obviously if you are using other group(s) than APQ User for access to apps, then the relevant end-user groups for app access should have READ (not WRITE) access to the apps which they require and blank or NONE access to all other Public Apps.
0 Comments
Add your comment