Results 1 to 7 of 7

Thread: UDO Best Practice

  1. #1
    Member
    Join Date
    Oct 2001
    Location
    New Zealand
    Posts
    440

    UDO Best Practice

    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!
    Contract JD Edwards Development Consultant.
    EnterpriseOne Xe through 9.2. Windows/Unix/OS400. SQLServer/Oracle/DB2 for i.
    ER, C/C++, BI Publisher, SQL, DSI dcLink

  2. #2
    Senior Member Larry_Jones's Avatar
    Join Date
    Nov 2000
    Location
    Spokane, WA, USA
    Posts
    3,267
    Makes sense to me. Same route we're going
    Larry Jones
    E1 9.2 - TR 9.2.2.6 on Win 2016 R2. SQL Server 2016
    Wintel, BI Publisher

  3. #3
    Member
    Join Date
    Oct 2001
    Location
    New Zealand
    Posts
    440
    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?
    Contract JD Edwards Development Consultant.
    EnterpriseOne Xe through 9.2. Windows/Unix/OS400. SQLServer/Oracle/DB2 for i.
    ER, C/C++, BI Publisher, SQL, DSI dcLink

  4. #4
    Quote Originally Posted by jolly View Post
    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.
    Tyler F.
    E1 9.2 | TR 9.2.2.4 | AS400 iSeries 7.2

  5. #5
    Member
    Join Date
    Oct 2001
    Location
    New Zealand
    Posts
    440
    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?
    Contract JD Edwards Development Consultant.
    EnterpriseOne Xe through 9.2. Windows/Unix/OS400. SQLServer/Oracle/DB2 for i.
    ER, C/C++, BI Publisher, SQL, DSI dcLink

  6. #6
    Yes you can. It's stored in the F952460 table in central objects, in the UODFLTUDO column.
    David Shirtliff

    E1 9.2 | TR 9.2.2.5 | Ent: RHEL 7 | DB: Oracle 12.1.0.2.0 on RHEL 7 | JAS: WebLogic 12.2.1.3.0 on RHEL 7 | Dep: Windows Server 2016
    Transform | RFSmart

  7. #7
    Member
    Join Date
    Oct 2001
    Location
    New Zealand
    Posts
    440
    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...
    Contract JD Edwards Development Consultant.
    EnterpriseOne Xe through 9.2. Windows/Unix/OS400. SQLServer/Oracle/DB2 for i.
    ER, C/C++, BI Publisher, SQL, DSI dcLink

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.