In R3 role design , "filling character" for org level required

[Former Member]

Hi All,

I am designing a role in R3 system , wherein I want to maintain a particular set of values in Org Level. For example , my values for org level are as below

A1YZ

A2YZ

AMYZ

ADYZ

where second character can be any character , but first character and last two characters are fix. So I am searching any filling character which can replace second character such that it includes all the values for second character. eg. something like A+YZ.

Can anyone please suggest me this filling character ?

[jörg_weichert]

have you read OSS Note 549485 - FAQ: General questions about authorizations

[1] Question: Can wildcards be used in authorizations?

Kind regards

Joerg

[Former Member]

Hi Jorg,

Thanks for the reply.

I went through the note you suggested as well as some of the others also , but now my issue is something else.

There are no wildcards in the value which I need to maintain. But there is one pattern in the values. Eg.

A1YZ , A2YZ , AMYZ , ADYZ ,etc ,etc...

These are the values I need to maintain at org level. Second character is variable and first and last two characters are fix , and I want to know if there is some special charater which can be used in place of second charater so that it can accept any value for second character.

I cannot use AYZ , coz it will be considered as A only. So any special character for that ??

[Former Member]

Hi,

There are no wildcard values that can be used in org levels that will give you what you want. If this is a strict requirement then this should have been considered (by the functional teams + security input) when they were defining the naming structure for that particular data object. Unfortunately this is a common occurrence, especially around things like cost & profit centres.

[former_member80629]

Yes, you cannot use a wildcard in between characters. I would say that you would have to list out all the values, future values, or revisit your naming convention as Alex mentioned.

[Former Member]

Hello ,

I was just interested to know why you are so keen on using * like characters in the org levels? Are you working on a very large range of values?

Warm Regards,

Arka.

[Former Member]

You need to consider this restraint before you design the naming convention.

If this is in your own code you could consider first checking the authority of the user for the limited length of the field and then changing the value being checked against to check again against the second namespace in the convention you are trying to achieve.

But... this will make your authorizations a labyrinth of room to make errors in! People with full authorization (*) or the full range might not pass the second check if it is a real wildcard.

I would change the convention or maintain the explicit values.

Which field is it?

Cheers,

Julius