Restricting SM30 via auth. groups, any flaws in thinking?

Question

Hi,
I got a request to assign SM30 to a role as table J_1IEWT_ACKN_N needs to be maintained monthly. I checked an earlier thread regarding this table, and in this case maintaining table in DEV + transport is also not accepted.
This role also includes other table maintenance activities (period opening/closing, exchange rate maintenance), but for these SM30 is not required. As this role would now include SM30, it would possibly grant access to quite a bunch of tables (through S_TABU_DIS, DICBERCLS values KC and FC31).  User with this role would not have any other roles.
I created a Zxxx-authorization group in SE54, assigned it to the J-table and then included this auth group to S_TABU_DIS object.
As this role only needs access to a few tables, I was thinking of changing the authorization group assignments of these tables from KC/FC31 to Zxxx and then giving only DICBERCLS value Zxxx to the role.
Does this sound like a reasonable solution? Can I just change the auth group assignments of the tables in SE54 or does this have any consequences that should be acknowledged and that I'm not aware of?

Answer 1

You should try to find an existing group which contains data with the same classification as this one, and use SE54 to assign the value to it. Possibly, if the correct set of users are already classified for that group then you don't need to change anything inthe roles.
If nothing which already exists matches the classification of the data, then classify it yourself by creating the Zxxx group and assign it via Se54.
If Z-groups already exist, as for the documentation on the concept so that the one you create or use is conform with the intended concept and naming conventions.
There is nothing wrong with a Z-table authorization group.
Cheers,
Julius