Oracle Apps Notes

A collection of my random notes, primarily on Oracle Apps

Read-Only DFF Segments

Converting normal fields in Oracle Applications Forms into read-only fields is a fairly common requirement and it can be achieved quite easily using Form Personalization. All you need to do is to set the ‘ENABLED’ property of the item to ‘FALSE’.

Read-only Field using Form Personalization

With Descriptive Flexfield Field(DFF) segments however, things become a little more complicated since DFF segments cannot be modified through Form Personalization. Metalink Notes#1289789.1 and 735423.1 explain why it is not possible to alter DFF segments through Form Personalization.

So, coming back to the original question- how do we make a DFF segment read-only? Well, there are three ways:

  • By implementing Security Rules. Click on the link for more details.
  • Through CUSTOM.pll using the FND_DESCR_FLEX.UPDATE_DEFINITION() API. This method will enable or disable the entire DFF and not individual segments. Click on the link for more details.
  • By populating the Value Set of the DFF segment dynamically at run-time with a single value. This approach is based on the premise that if the Value Set of the DFF segment contains only one value then the segment effectively becomes a read-only segment. Here is how you do it:
  1. Create a custom table and register it with AOL. It should contain at least two columns- one for storing the segment value, one for storing the user_id.
  2. Use Form Personalization in the form containing the DFF to populate the table created in Step#1 with the value that you want the DFF segment to display and the user_id of the user accessing the form. You can do this from the WHEN-NEW-FORM-INSTANCE or any other suitable trigger and by using the FORMS_DDL builtin. The sequence of commands in the builtin should be:   delete from custom table any existing records created by the current user – insert value into custom table along with the current user’s user_id – commit.
  3. Create a table validated Value Set based on the custom table and add ‘column_name= :$PROFILES$.USER_ID’ (where column_name is the name of the column in your custom table which stores the user_id) in the where clause to ensure that only the record created by the current user is returned.
  4. Attach the Value Set created in Step#4 with the read-only DFF segment.

We need to store the user_id and access the Value Set based on the correct user_id because in a production environment, the same Oracle Applications form might be accessed concurrently by multiple users leading to multiple records being inserted in the custom table. Since the success of this approach depends on a single value being returned, so we need to limit the values returned by the value_set using the user_id.

Advertisements

10 responses to “Read-Only DFF Segments

  1. Shyam September 2, 2011 at 9:16 pm

    I am trying the option By populating the Value Set of the DFF segment dynamically at run-time with a single value, Can you please tell me how to get the user id and value to populate in to table.

  2. oracleappsnotes September 3, 2011 at 12:35 pm

    Hi Shyam,
    You can get the user_id by using the syntax, ${ps.user_id.value} while the value will be what you want to populate the value set with.

  3. Jonathan September 7, 2011 at 3:39 am

    Thanks for the amazingly detailed instructions. This worked perfectly for me. Thanks!

  4. oracleappsnotes September 7, 2011 at 10:42 am

    Glad that you found it useful, Jonathan.

  5. Kartik February 21, 2012 at 12:29 pm

    Hi,

    I am trying this for the first time. Could you please confirm , in this link,

    http://erpschools.com/articles/make-dff-segment-readonly-through-security-rules

    They use the same process of security fields without the need to create/maintain a new table. How different is this process from what you have listed and any advantages? I think in that link they use valuesets.

    Thanks,
    Kartik

    • oracleappsnotes February 21, 2012 at 6:45 pm

      There are no such advantages/disadvantages on either side. Your choice depends on your requirement.
      One major difference is that in case of security rules, you are allowing one user can enter any value while preventing a different user from accessing specific values. While in the method shown in this post you are restricting the user the user from making changes by ensuring that only one value is available to him whenever he accesses the segment.

  6. Partha May 8, 2012 at 1:54 pm

    Can you provide screen shot of the process.

  7. oracleappsnotes May 8, 2012 at 10:19 pm

    Partha, it has been a long time since the post and I do not have the screenshots. However, if you understand the steps well, the screenshots are not required.

  8. Islam November 12, 2012 at 7:36 pm

    Hi,
    thank you for this topic, but when i go with security rule option , i found that if there are two segements on a DFF , and i want to make one of them read-only & the other enterable ,when a user open this DFF using the responsibility that assigned to that security rule , the user will find one segement read-only & the other is enterable ,& if the user try to edit the enterable filed & try to save , he got the error msg that regards to the security rule & he cann’t save the change although the changes was done on the enterable filed ;
    would you help on that?
    thanks

  9. pankaj March 8, 2016 at 3:37 am

    Thank You

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: