 DFF [message #124915] |
Wed, 22 June 2005 06:00  |
emoumen
Messages: 3
Registered: June 2005
Location: Paris
|
Junior Member |
|
|
Hi All,
I've a DFF with 5 attributes. According to a condition, i want to enable (or disable) only attribute3 and attribute4.
Need a Help
Many Thanks
El Houssin
|
|
|
|
|
|
| Re: DFF [message #125166 is a reply to message #125143] |
Thu, 23 June 2005 11:14  |
emoumen
Messages: 3
Registered: June 2005
Location: Paris
|
Junior Member |
|
|
Hi,
here the explanation:
a) i create a profile
b) if the user has the profile value = 'Y', he can modify all attributes (Attribute1 , 2, 3, 4 and attribute5)
c) if value of the profile = 'N', the user can modify attribute1, attribute2 and attribute5 (fields of attribute3 and attribute4 are disabled)
Hope this help
Many thanks
|
|
|
|
|
|
| Re: DFF [message #125194 is a reply to message #124915] |
Thu, 23 June 2005 14:28 |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
Vikrams is correct. Everybody I've talked to about enabling/disabling DFF's (even in parameter form) based on values within the form requires a whole new custom form OR the "tweaking" of a seeded form (this is NOT recommended AT ALL!). As far as I know the application can only obtain values from DFF's and analyzing that value, can create a subsequent LoV DFF. They cannot disable/enable or otherwise alter the functionality of the form.
Sorry! I know, this is something I'd like Oracle to implement as there have been numerous occasions that I could have used that same functionality!
Regards,
Steve
|
|
|
|
| Re: DFF [message #125396 is a reply to message #125166] |
Fri, 24 June 2005 16:41 |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
There is a way you can do something like this. The user would still be able to alter the content of the DFF, but not to save the changes.
What you need to do we are talking a LOV or a free text flexfield. For the first you would use a table validated value set and ensure that the query returning the valid values would just return the current value of the DFF if the profile value is 'N'. In order to find the current value you will probably have to use the :block.field syntax. This is strictly speaking not recommended by Oracle as it might not work in the future. It certainly does not work in non-Form products.
For free text flex fields you make the magic happen using some PL/SQL in a value set with special validation.
--
Aleksander Dragnes
|
|
|
|
| Re: DFF [message #125512 is a reply to message #125396] |
Mon, 27 June 2005 03:29 |
emoumen
Messages: 3
Registered: June 2005
Location: Paris
|
Junior Member |
|
|
Thanks for your anwser.
I've done this, but what i want is to be able to disable attribute3 and attribute4
Regards
El Houssin
|
|
|
|
| Re: DFF [message #125562 is a reply to message #124915] |
Mon, 27 June 2005 10:51 |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
You've done what?
Again, the functionality you are asking for requires either:
A tweak to the seeded (out-of-box) form OR the construction of a function that will analyze the condition and make the form changes from within the custom.pll library. Again, this is not recommended if you are not sure of EXACTLY what you are doing.
As far as Adrognas response, using the :block.item syntax is only for the tweaking of a seeded form (which if tweaked, is no longer seeded. This means that subsequent patch sets will overwrite your changes!) The best way (if it is absolutely necessary, would be to tweak the custom.pll library, but you should be well-versed in PL/SQL and Applications before you attempt something like this)
Again, it is probably more effort than it is worth when you can just tell the user the valid combinations via documentation. But I also realize that most users when told to read the documentation say 'Oh yea, sure' then never read it and call you a week later asking why they can't do it and it turns into a 3-ring circus. Sigh, the life of an IT professional...
|
|
|
|
| Re: DFF [message #125569 is a reply to message #125562] |
Mon, 27 June 2005 14:37 |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
| Steve Corey wrote on Mon, 27 June 2005 17:51 |
As far as Adrognas response, using the :block.item syntax is only for the tweaking of a seeded form (which if tweaked, is no longer seeded. This means that subsequent patch sets will overwrite your changes!) The best way (if it is absolutely necessary, would be to tweak the custom.pll library, but you should be well-versed in PL/SQL and Applications before you attempt something like this)
|
Steve, I think you misunderstood. I was not talking about customizing the form, just creating value sets where the values possible values depend on whether the profile option has been set or not. The :block.item syntax is just to be able to access values in the form to help determine which record is being edited. Unless you alter a seeded value set and name your new value set according to the guidelines, nothing will be overwritten in subsequent patching. However, the functionality might break if the form is changed in a future version, but the same can be said of any extension achieved using the CUSTOM Library or Forms Personalisations.
I also wonder whether it at all is possible to change the DFF pop-up window using the CUSTOM Library. There certainly is no CUSTOM Library events fired when moving from field to field in it and it is not possible to use Examine on the Help menu to find the name of block and item. Have you ever succeeded in doing this?
I think my solution defining value sets that only allows people with the profile option set to alter the DFF attributes in question is about as far as you can get without modifying the form, which is something I generally do not recommend as it only will lead to a lot of maintenance work, and in this case not adding much in the way of value. If the user cannot alter the attributes, what does it matter that he initially might think that he can? If this had been a self-service application I could see the point, but I think one should be allowed to count on professional EBS users to live with some quirks as long as they cannot do anything wrong.
BTW: There is another and simpler way of ensuring that users without the profile option set cannot alter the DFF attributes. You can do it using a trigger on the underlying table. This is of course not supported and might break standard functionality.
--
Aleksander Dragnes
|
|
|
|
| Re: DFF [message #126575 is a reply to message #125569] |
Tue, 05 July 2005 14:12 |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
Adragnes -
I suppose I did misunderstand, although it is difficult for me to ascertain if I did or not. Heh heh.
In any event, I agree with the conclusions you reached as I did not realize your users would be well-versed (our users are not... at least not yet) in EBS. I have had to make some changes that just seem a tad absurd to accomodate those that would refuse to read documentation. I suppose I should not use my business as a template for others, so my apologies.
Regards,
Steve
|
|
|
|
| Re: DFF [message #126674 is a reply to message #126575] |
Wed, 06 July 2005 03:11 |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
I guess I was lucky with my users. At the time of writing I was on a project where the users have been using EBS since before 10.7, but let me try to make myself more clear about my proposed solution above.
In the example below I will limit myself to discussing the case where the user has to pick the value from an LOV. Let us assume the following:
- The DFF is only set by user in a Oracle Forms Form.
- The total list of possible values have been defined in some value set with name 'XXA'.
- There is some block with name 'BLOCK' with an item 'ID' in the form that hold the value of the primary key of the record in the database.
- The table with the records is called 'RECORDS' and the primary key column is called 'ID'.
- The DFF is to be "enabled" only for users with profile option 'XX_ENABLED' = 'Y'.
What I propose to do is to create a new table-validated value set 'XXB' that will only allow users with the profile option 'XX_ENABLED' to alter the value in the DFF. I think this can be done like this. (I have not tested this so if you want to try it yourself you might have to iron out some wrinkles):
Tables:
FND_FLEX_VALUES FFV, FND_FLEX_VALUE_SETS FFVS
Where/Order By:
WHERE ffvs.flex_value_set_id = ffv.flex_value_set_id
AND /* Value in XXA value set */
ffvs.flex_value_set_name = 'XXA'
AND /* Enabled */
ffv.enabled_flag = 'Y'
AND SYSDATE BETWEEN NVL(ffv.start_date_active, SYSDATE – 1)
AND NVL(ffv.end_date_active, SYSDATE + 1)
AND /* Always allow present value of DFF in record */
( ffv.flex_value IN ( SELECT r.attribute1
FROM records r
WHERE r.id = :block.id )
OR /* Allow all if profile option value is set to yes */
:$PROFILE$.XX_ENABLED = 'Y' )
I hope this helps.
--
Aleksander Dragnes
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
