The interpretation of star (*) seems to be the problem.
If I replace the line
it seems to work, I think.
I am sure you know what all I am stating below. But I will state it anyway just to explain my understanding or my thoughts.
In SECTION ACCESS, * means listed values, not ALL values.
In the SECTION APPLICATION part, * is a wild character to mean any number of characters e.g. in search string, and all fields in LOAD/SELECT statement. As a data value, I am not sure it means ALL data. If I am wrong, please correct me.
Thanks for the quick response Krishnamoorthy. I`m aware of the logic which you have mentioned above to replace (*) with all countries.. i just gave an example of three countries, on my original application i have many countries and the level of fields the security to be implemented is also many. so it would be very difficult to replace (*) with all the values manually.
One more option would be extracting all the data from Country master table and joining that with section access table where ever I see (*). but this is also cumbersome, since i have many permutation combination like Country, Region, Territory, District and so on..
Hope i have explained my problem clearly, if not please let me know.
Thanks for your respone. I have tried this earlier. This behaves differently when i i give more access to the user3. i.e. now we have for user 3 Country --> 'All Country' and Region --> 'A'.
I modified the access for user 3 as Country --> 'All Country' and Region --> 'A' and
Country --> 'AUS' and Region --> 'All region' .
But with this access, when user 3 loggs in to the application, user 3 is able to see only Country--> 'AUS' and Region --> 'A' But i expecting him to see 'All Countries' with Region A and 'All region' in 'AUS'.
Attaching the application which i have tried with the above scenario.
Yes, usersare going to access application via client to a server? Can you please tell me, how Section access behaves different in either case?
In this case, you will have to loop all possible combinations. Using client means that, even when the user has given ACCESS as ADMIN, it will behave as USER instead. Besides, the blanks will not work in the server environment and you will need to use either a value or the "*" sign.
Reduction in section access doesn't more than one value per line, except for the "*", and in your example, AUS and A are excluding each other, or, at least, are not cumulative (that is what I understand you want to get for user 3, full access to region A (regardless the country) plus full access to country A (regardless the region).
You can do use two different reduction fields in section access and that will work if both fields are unrelated, and this is not the case. Again, to understand the data you are allowing one user to see, select the values in the fields corresponding to their reduction fields in section access, go to the File menu, Reduce Data, and click on Keep Possible Values.
What happens here? According on how your model is built, COUNTRY = 'AUS' and REGION = 'A' are incompatible (you cannot select both values in your model). Once you allow the user to see COUNTRY = 'AUS', three values in REGION (A, B and C) are available. In other words: you either see all regions and one country, or all countries and one region.
I think you need to create a more complicated model of groups since section access is not so flexible as to say "all values in country where region equals to 'A' but all regions where country equals to 'AUS'".
I'd love to hear from anyone that has faced this issue and see how they worked that around.