UDO Best Practice

jolly

VIP Member
Hi all,

My client is looking at using UDOs where possible in their 9.2 upgrade, to eliminate modifications to custom JDE objects. We've identified a number of patterns and ways to use UDOs to eliminate them so that's all looking well and good.

Now we're looking at how we manage these UDOs. All the UDOs for the upgrade will be designed and built by the developers as e they are working their way through the modified object list, retrofitting modifications that can't be replaced by UDOs. I expect they will do this in DV and request to share when ready. Someone will be tasked with a quick sanity check before sharing and promoting into PY for testing and approval.

Does this make sense so far?

I think initially when 9.2 goes live, UDOs will still be designed and built within the IT department to keep the application look standardised, so business users outside IT would have VIEW security for UDOs but no access to create/publish/modify UDOs.

Also, we would like to lock in certain UDOs such as queries and personal forms (but not layouts) so the users can't change selection of those at runtime. Is that possible? Where a personal form or query has been set against a form, we want to ensure the end users are going to work with that UDO in effect.

Thanks in advance for any suggestions and corrections!
 
Cheers Larry. I am new to this and discovering new things all the time - for instance if you create a UDO over a form, say a Grid Format, it is against the version you created it on. However P98220U has a row exit that allows you to copy the UDO to any or all other versions of the form. Very helpful if you have a hundred versions of P4210!

What I can't see yet is how to lock the UDO in place for users. Easy enough to make your Grid Format UDO the default, but how to stop the users from reverting to the "Show all columns" original?
 
What I can't see yet is how to lock the UDO in place for users. Easy enough to make your Grid Format UDO the default, but how to stop the users from reverting to the "Show all columns" original?

As far as I know, it is not possible to restrict users from selecting "Show all columns" or the equivalent for other UDOs that you referenced, take a look at Doc ID 1966429.1.

As a note since you mentioned being new to UDOs, be careful when selecting a UDO as a "Default". Once this option is selected and saved for a UDO, it cannot be reverted. You will have to delete and re-create it if you wish for a UDO to no longer be a "Default". Also in reference to your first post, at our company we allow users to create their own personal Grid Formats and the ability to modify them, but we do not allow them to publish UDOs.
 
Yeah, our pre-upgrade 9.0 users are using GridFormats so that will continue...

Re the default attribute not being resettable... I wonder if that can be done through SQL?
 
Yes you can. It's stored in the F952460 table in central objects, in the UODFLTUDO column.
 
Hi all,

Turns out that (as of 9.2.4) you can restrict the base form of a Personal Form... by using *BASE ... So the users can be restricted to one or more Personal Forms, but be prevented from reverting to the "No Personalisation" base form.

See Doc ID 2072336.1

Happy daze...
 
Back
Top