Need SMTP_ADDRESS Mandatory on New User Create/User Maintenance

[Former Member]

Is there a way to require entry of email address upon new user creation or user maintenance without an ABAP enhancement?

It appears that function module ADDR_PERS_COMP_COMM_MAINTAIN writes email address to database for users, but before I try to enhance the code, I'd like to see if this is a change that can be made without code modifications.

Use of report RSADRCK7 is not feasible; users would need to be done one at a time.

This requirement would apply only to functions (SU01) by BASIS/Security; users must remain unable to maintain their email address via System>UserProfile>Own Data.

[mvoros]

Hi,

unfortunately, there is no BADI for user creation. So the best way is to find a suitable implicit enhancement point in SU01.

Cheers

[Former Member]

There are some users in the system for whom you would certainly not want an SMTP address...

What if I can send work items to WF-BATCH from my favourite Internet Cafe? If you ever try to change DDIC's password?

Please explain what you are trying to achieve. For sure there is a better way.

Cheers,

Julius

[Former Member]

enhancement inserted for SU01, screen 0900, to error when SZA5_D0700-SMTP_ADDR is initial, in SAPLSZA5, form D0700_OK_CODE.

Thanks for the replies.

[Former Member]

Tomorrow I will chck in EhP 3. In EhP 1 it does not work.

Regardless, I think the idea is questionable...

Cheers,

Julius

[Former Member]

> enhancement inserted for SU01, screen 0900, to error when SZA5_D0700-SMTP_ADDR is initial, in SAPLSZA5, form D0700_OK_CODE.

If that does not work, then the easiest option is a check after the user creation to verify that all users who are meant to have an SMTP entry in the address data, also have one (from the correct domain, etc...).

Alternately, you can create a standard transaction variant for SU01 and change the screen of the address data tab. When saving (or proceeding to the next screen), the address data must have been maintained.

The first option is certainly much easier and less intrusive to implement...

Do you also use self-registration scenarios? Is that the reason for your question?

Cheers,

Julius

[Former Member]

As so often happens, now that the "real" user is involved, the requirements have changed a bit from my original understanding.

Thanks, Julius, for your replies. Your points are excellent, and based upon latest email requirements from the user, I've created the a screen variant to show and I like the way it works. Now, if only the user likes the results.

[Former Member]

If you do not give us "sufficient" information about the requirements, then discussing solution options is a bit futile.

That the requirements change all the time is however normal

Cheers,

Julius

[Former Member]

User requirements changed, therefore re-opened this post.

[Former Member]

Transaction returned to SAP standard.

[Former Member]

Dave, what did they not "like"?. In situations like this I take the "tough luck" approach.

As Julius mentioned, the standard variant is very commonly used to restrict this. I believe you can also modify the screen but that counts as a change.

[Former Member]

Thanks for your reply...but not going to take a "tough luck" approach these particular users.