Authority Check On Selection Help for DROPDOWN_BY_INDEX possible?

[Lukas_Weigelt]

Hi folks,

System Info: ECC 6.0 EHP4 SP56 ST11 (soon to be EHP6)

I've got a requirement where the enduser is forbidden to see certain values of a dropdown_by_index value help. However, the values that have to be made invisible must still "be there", I must not delete them, because all the values of this value help are being used from another component which would misfunction otherwise.

As far as I've experienced/I know there is no event for WDA dropdown_by_index as in normal Dynpros "on selection screen value help" or the like. This is the point where I don't know what to do or rather whether the requirement is even achievable .

It would be nice if somebody could comment this, I can provide more information and the concrete use case if needed.

Best regards + Cheers

Lukas

[amy_king]

Hi Lukas,

Another option could be to check the name of the current component or application and modify the value set as needed if the user is using the drop down from the restricted application.

Cheers,

Amy

[sreenu_b2]

Hi Lukas,

If you want to retain the same values of Drop down ,and also restrict the user with certain values ,

Then you can try the below approach.

1. Don't use the context which has all the values required in the drop down . Instaed Create a new context and use it for drop down UI .

2. Populate this context with the values of origial context  and while populating restrict the entries  .as per your requirement

3. On any entry selection  from this DDBI UI , set the related attribute value in the Original Context node

[Former Member]

steps to do this.

1. create a methdo call it in wddoinit .

2. in newly created method  call logic to get all values from database and put in internal table(INTERNAL1).

3. create another internal table (INTERNAL2) as per your authority check put value from internal1 to internal 2

4. bind internal2 table with attribute  with class if_wd_context_element method

  set_attribute_value_set .

reward if helpful

[Lukas_Weigelt]

However, the values that have to be made invisible must still "be there", I must not delete them, because all the values of this value help are being used from another component which would misfunction otherwise.

Exactly this is what does NOT work. Once I manipulate the context, the dependant WDYN Comp misfunctions, the context must remain untouched (it's a complex standard application, not my own).

Any other thoughts?

Cheers, Lukas

[Former Member]

in on_select method of dropdown as per authority you can display error message

[former_member211591]

Hi Lukas,

are you able to enhance the "value-set-populating method" of your F4 help?

If yes, you could add a loop at the end of the method in which you drop values the user is not allowed to use. (You also could check from which programm the "value-set-populating method" is called and thus decide if to trigger value-dropping or not.)

Regards,

ismail

[Lukas_Weigelt]

Thanks for the replies so far,

@ Jitendra, Yes, throwing an error message was my emergency-case-solution but only if the original requirement fails to be achieved, because if I do it that way, there will be the legitimate question "why is the end user able to select entries he is not allowed to select".

@ Ismael, This won't work either. As I said earlier, any means to manipulate the search help/context itself, no matter whether it's via direct alteration of the tables before binding or authority checks and the removal or the popolation method if there is any, will lead to the breaking of the application. The context must remain untouched.

Any other thoughts? I'm getting the feeling it really isn't possible because there is no event 'at opnening' the search help and the only common appraoch is manipulating the context, which I can't.

Cheers, Lukas

[former_member211591]

Why don't u just manipulate the context node holding the values due to the authorization within e.g. wddomodifyview?

Post (or pre) enhance WDDOMODIFYVIEW and drop the values you don't want to display.

[Lukas_Weigelt]

Another option could be to check the name of the current component or application and modify the value set as needed if the user is using the drop down from the restricted application.

Why don't u just manipulate the context node holding the values due to the authorization within e.g. wddomodifyview?
Post (or pre) enhance WDDOMODIFYVIEW and drop the values you don't want to display.

Okay, I'll have to provide the use case otherwise it isn't comprehendable.

The Application I'm talking about is FITE_EXPENSES, within the 2nd FPM Step two WDYN Components are used; FITE_VC_RECEIPTS and FITE_VC_CREDIT_CARD_ITEMS. In case I drop any of the values from the Expense Type DDBI UI context/global attribute in FITE_VC_RECEIPTS, the following happens:

When I select a credit card item in FITE_VC_CREDIT_CARD_ITEMS that contains an expense type I would theoretically have dropped from the context/global attribute in FITE_VC_RECEIPTS and I try to assign this record set from the CC-Buffer to the expense claim there are several complex checks deep within the Backend Logic of the frame program (outside the WDA framework) which amongst other things, check against the context/value help/global attribute retrieved from the web memory of FITE_VC_RECEIPTS within the delegation of the two components. If the respective expense type is then not found (because I dropped it due to authorizations or whatever approach used), it is reset to blank and there is a crippled record set in FITE_VC_RECEIPTS which can then only be deleted.

This is the reason I must not alter this value help at all costs, it doesn't matter what approach I use to do this, IF I do it, it's all messed up. That's why I was searching an approach to leave the context untouched and simply not display some of the entries (whereas I'm nearly sure this possibility doesn't exist in the WDA framework).

Cheers, Lukas