How to delete expired roles?
Here are 3 notes you may want to review to see if there
is any helpful info, plus some documentation that may be helpful for
others....we are going from 40B to 47 and have had a few issues with role
A D V E R T I S E M E N T
Notes: 312943 504412 & 313587
First, the report PFCG_TIME_DEPENDENCY is functioning
as designed. It was not designed to remove activity groups.
Second, in transaction SU10 you must have the valid
from and valid to fields filled in with the actual dates, 04/08/2002, in order
to remove the invalid activity group. You need to be sure that the remove user
radio button set in the role tab. But in the profile tab, the add user radio
button is selected by default. What you have to do is go to profile tab and
select the remove user radio button. You have to make sure both role and profile
has the same radio button selected, i.e. remove from users. Only then when you
click save, it will allow you to delete the role from user.
In transaction SU10, you need to complete the following
1. Click on the Authorization data button.
2. Entry the users name, latimerc
3. Click on the execute button.
4. Put a check in front of the users name.
5. Click on the transfer button.
6. Now highlight the user.
7. Click on the pencil button.
8. Click on the Activity Groups tab.
9. Enter the profile name (PM_NOTIFICATION_PROCESSOR).
10. Enter the valid from and valid to dates (04/08/2002).
11. Change the radio buttons to remove user from both the
Activity Group and Profile Tabs.
12. Click on the trash can.
In another customer message the following was provided
We don't have a regular functionality for mass deletion
of roles. But if you want to avoid the deletion by hand or with an own created
report, I would suggest the following:
The attached note 324962 includes the report
ZDELETE_RY_T_AGRS which could delete all roles with names like 'T_....' or
'RY....'. The report gives you a list of all these roles and deletes then the
selected ones. You can modify the report to get all your roles in the selection
list. Therefore you have to change the following:
SELECT * FROM AGR_FLAGS INTO TABLE L_AGR_FLAGS
WHERE FLAG_TYPE = 'COLL_AGR'
AND FLAG_VALUE = 'X'.
SORT L_AGR_FLAGS BY AGR_NAME.
LOOP AT SINGLE_ACTGROUPS WHERE AGR_NAME+11 <> SPACE AND
( AGR_NAME(2) = 'T_' OR AGR_NAME(2) = 'RY' ).
LOOP AT SINGLE_ACTGROUPS WHERE AGR_NAME+11 <> SPACE.
READ TABLE L_AGR_FLAGS WITH KEY AGR_NAME =
Text from an additional customer message as further
- go on role tab
- select remove from user
- enter ZR.PRD.GENERIC and date : 06/04/2002 12/31/9999
- go to profile tab
- select remove from user
- do the same for ZR:HR:ESS from 01/01/2002 to 12/31/9999
from date for testid was 01/01/2002 and testid2
02/01/2002 and the 2 assignement were deleted And the roles were
removed from the 2 UMR.
So it works as designed.
What are user groups and how can we use them?
Your auditer asked you to implement user groups in SAP, but you have no
idea what are user group.
Transaction SUGR - have a look. Purpose
for example is to give certain system admin rights to unlock / change password
only to a given user group. You assign user group to an user id via
User group can be used for different reasons and in different way.
In the latest versions of SAP, actually two types of usergroup exist, the
authorization user group and the general user groups.
Naturally the main reason of user groups is to categorize user into a common
The authorization user group is used in conjunction with
S_USER_GROUP authorization object. It allows to
create security management authorization by user group. e.g. you can have a
local security administrator only able to manage users in his groups, Help-Desk
to reset password for all users except users in group
The general user group can be used in conjunction with
SUIM and SU10,
to select all the users in a specific group. User can only be member of one
authorization user group but several general user group.
One of the Primary uses of user groups is to sort users into logical groups.
This allows users to be categorised in a method that is not dependent on
User Groups also allow segregation of user maintenance, this is especially
useful in a large organisation as you can control who your user admin team can
maintain - an example would be giving a team leader the authority to change
passwords for users in their team.
The most important factor identified is that the lack of user groups is an
indication that there may be problems with the user build process. This is very
"fuzzy" but is a bit of a warning flag.
The Auditors job is to provide assurance that SAP is set up and administered
in a way that minimises risks to the financial data produced. If the only thing
they have picked up on is the lack of usergroups then you will be fine.
If you are in any doubt whatsoever ASK THE AUDITOR. They would have produced
a report listing why they feel there is a risk by not having User Groups
implemented. If you feel that the risk is mitigated by other measures then let
them know. It works best as a 2 way process and both parties can learn