Variant / or / parameter Tranaction for a report

[Former Member]

I want to create a transaction code for a report .

This transaction code should load a variant ( Protect a parameter field ( Value = xyz & user can not change it ) .

Can someone tell me how to proceed ?

Thanks

[former_member194669]

Try this way

Create the variant

In the Initialization event

data : v_field like dd03l-fieldname.
  move sy-sysid to v_sysid.
  call function 'RS_VARIANT_CONTENTS'
    exporting
      report               = 'YTCI3008'  
      variant              = v_sysid   " May be your variant name is same report name
    tables
      valutab              = i_params
    exceptions
      variant_non_existent = 1
      variant_obsolete     = 2
      others               = 3.
  if sy-subrc eq 0.
    loop at i_params.
      assign (i_params-selname) to <fs>.
      <fs> = i_params-low.
    endloop.
  endif.

Then

Loop at screen.
  if screen-name = 'XXXXX'.
   screen-input  = 1.
   modify screen 
 endif.
endloop.

a®

[Former Member]

Hi,

Please check SE93 transaction. When you are creating a new transaction code.

There is an option Transaction with Variant(Variant transaction)

Thanks,

Chaitanya

[Former Member]

Hi Rohan,

Go to SE80, In the left navigation panel, click on repository browser and in the drop down box select program and enter your program name and then hit enter,

Make sure that your program is activated.

Create a variant and mark the protected field for the field you want to protect,

right click on your program name and then click on create -> transaction.

In the new - window give the transaction code and the short text and select the radio button which says program and selection screen.

In the text box start with variant enter the variant name you have created , give the program name, and then save the transaction.

Your transaction code is created with the variant you specified and also the field you want to be protected will be protected too.

Regards,

Siddarth

[Former Member]

Thanks all .

[Sandra_Rossi]

Be careful, with that solution, the user can unprotect the field by saving to another variant.

[Former Member]

It would be better if in all the variants it is protected, as the requirement is in such a way that the user is not supposed to enter any other value...

Hence, just take care that all the variants have the field protected

[former_member194669]

Sandra,

I my reply i pointed create a variant same as a report name. and get protect the variant , (so that noboday can change the values) then using fm

data : v_field like dd03l-fieldname.
  move sy-sysid to v_sysid.
  call function 'RS_VARIANT_CONTENTS'
    exporting
      report               = 'YTCI3008'  
      variant              = v_sysid   " May be your variant name is same report name
    tables
      valutab              = i_params
    exceptions
      variant_non_existent = 1
      variant_obsolete     = 2
      others               = 3.
  if sy-subrc eq 0.
    loop at i_params.
      assign (i_params-selname) to <fs>.
      <fs> = i_params-low.
    endloop.
  endif.

so if user create another variant also will not be an issue.

Your response please..

[Sandra_Rossi]

okay the user won't be able to change the protected field in the existing variants, but he will be able to create his own variant and unprotect the field, right? (or we may hide the SAVE button)

So, if the requirement is "the user must never change this field" (but I don't know what is the exact requirement), that may be an issue.

[Former Member]

The OP seems to be happy with the step-by-step (click-by-click) approach... but for those of you who want to discuss further...

There are 3 mechanisms which can be used in combination:

- The program group for P_ACTION = 'VARIANT' of S_PROGRAM (if protected).

- The sy-uname protection for the last person to choose the option.

- The global variant protection (client 000) for SAP and Customer variants.

See discussions about [VARCH|https://forums.sdn.sap.com/search.jspa?threadID=&q=VARCH&objID=f208&dateRange=all&numResults=15&rankBy=10001] for more infos.

But I also agree with what aRs was indicating in that if there is no obvious intention to submit the report via a selection screen which should be edited, then why add the parameter to the selection screen for the user?

Cheers,

Julius

[Sandra_Rossi]

Maybe I am not clear.

Even with the protection, I just wanted to warn that the user could change the value by creating a new variant. Thank you Julius for telling about the authorization object S_PROGRAM + field P_ACTION = 'VARIANT', without it we can't use the SAVE button. Another preferrable solution, according to me, is to setup a gui status without the SAVE button.

I agree that we may hide programmatically the parameter with LOOP AT SCREEN, but do it in the AT SELECTION-SCREEN OUTPUT event, not in the INITIALIZATION, because the user may also unhide the field by saving to a new variant (by initializing it from a TVARV(C) variable).

I don't understand aRs solution because he sets a field to INPUT mode (screen-input = 1) but the requirement is to protect it.

What do you mean exactly?

>

> - The sy-uname protection for the last person to choose the option.

sandra

[Former Member]

> Sandra Rossi wrote:

> Maybe I am not clear.

Perhaps I should have been more direct as well - this whole requirement sounds like a nonsense idea and the post which has been awarded the correct answer is questionable.

> Even with the protection, I just wanted to warn that the user could change the value by creating a new variant. Thank you Julius for telling about the authorization object S_PROGRAM + field P_ACTION = 'VARIANT', without it we can't use the SAVE button.

Yes, that is what S_PROGRAM does to prevent the SUBMIT of the program, or protect it using groups of programs for which the authorized users (P_ACTION = 'VARIANT') can both maintain and copy the variants of that program group and also submit the reports via their variants (SM37, SA38, shortcuts, etc), but not from the workbench (for that P_ACTION = 'SUBMIT' is required).

> Another preferrable solution, according to me, is to setup a gui status without the SAVE button.

I don't agree. The bigger problem here is that the report coding is not making the correct checks to determine whether the user can run it for what ever they are requesting. Hidding the selection screen or forcing it is mostly an indicator that the quality of the programming is questionable.

A well designed program should validate any input, return or process only the authorized output and provide messages or logs of that which was not returned or processed (or simply not proceed).

> I agree that we may hide programmatically the parameter with LOOP AT SCREEN, but do it in the AT SELECTION-SCREEN OUTPUT event, not in the INITIALIZATION, because the user may also unhide the field by saving to a new variant (by initializing it from a TVARV(C) variable).

Good comment. The user can be expected to influence or maintain directly their own user variables used in variants which are controlled by PIDs. That is also why variant values in selection screens etc.. should not be used for security purposes when they can be controlled by PIDs - they are not intended for that. They are intended for preferences, reusing the last criteria, etc. The user can influence their PIDs in many transactions and nagivation paths, or directly via transaction SU3.

> What do you mean exactly?

> >

> > - The sy-uname protection for the last person to choose the option.
> 

In transaction VARCH (but also via SA38 etc) there is a flag called "User Protection" or similar. This will protect the variant from modifications from anyone other than the user (sy-uname) who last flagged it and saved. Others with access to S_PROGRAM for that variant, will not be able to change the variant.

There is a way of unlocking these though... see OSS notes relating to RSVARENT.

This is a way of personalizing variants. It does not protect the program from being executed by others (also with the same selection criteria - if authorized) but prevents others from changing that specific variant. This can be usefull for variants used in periodic background jobs which should not be changed by someone who is not aware that this will create a potential mess.

There are a number of different designs and approaches one can take, depending on how the batch job administration responsibilities are defined and use of variants is intended.

But missing authority-checks in the necessary places is still a "no-brainer"...

Cheers,

Julius

[Sandra_Rossi]

Thank you Julius, or even Bravo !, you are very clear