User overrides are storing more and becoming very important for users and productivity. You can do lots with them, they follow you around – they are great. But if you are going to harness the power of them, you need to know some of the pitfalls / nuances. Here are a couple that are important.
In current releases, such as 8.97, new records will be created for each user when they launch the application. For example, if there is a *PUBLIC override on P01012, when the user launches that application, a new record in the F98950 table will be created using that users ID. This is working as designed and was a necessary change for the web client. If changes to the *PUBLIC user override are made, delete the users current overrides. Then the new *PUBLIC override will create the entries when the user launches the application. Please note that this is wrong, In my testing (9.1.3.4) this does not occur unless you change the UO, when you change it and log out – it’ll save it as an individual UO – of course it will not change public.
When promoting an interactive application within Object Management Workbench (P98220), the *PUBLIC User Override records for the application will be automatically promoted when the interactive application is promoted. Therefore, it is not a requirement that *PUBLIC User Override records be added to a project in Object Management Workbench in order to be promoted. However, individual override record (i.e. User Override record by User ID/Role) will still need to be added in the Object Management Workbench in order for it to be promoted. Wow, that is new for me… Might drag up rubbish from DV910 that you did not intend!
No comments:
Post a Comment