When you open a document on the server or by client, regardless the ACCESS you have set for them in Section Access, all users are dealt as USER (even when you have set them as ADMIN in the ACCESS field). My guess is that they are able to open the document on Desktop since they may be behaving as ADMIN.
I'd first try manually to select some of the users that cannot see their information, go to menu File, Reduce Data, and select "Keep Possible Values" to see what actual information is the user seeing.
If that works (if the user sees the information he is supposed to) I'd check that in the Settings menu, Document Properties, Opening, "initial Data Reduction" is checked and so it is "Strict Exclusion", and try to log in with any user, now that the reduction is taking place. As any user can log in and see all data, I'm assuming that instead is checked "Initial Selection based on Section Access".
Hope this helps.
Thanks for your reply, I appreciate it.
I tried to use the Keep Possible Values in desktop and that shows me only the Costs Centers I suppose to see. However, when I open the app in the browser It shows me everything.
I already have the "Initial Data Reduction Based on Section Access" option checked. However if I check "Strict Exclusion" and republish I am no longer able to even open the app. It keeps asking me for my username and password instead of getting from Active Directory.
Any other thoughts?
Igor Alcantara wrote:I already have the "Initial Data Reduction Based on Section Access" option checked. However if I check "Strict Exclusion" and republish I am no longer able to even open the app. It keeps asking me for my username and password instead of getting from Active Directory.
This points me to the fact that, somewhat, the section access and the rest of the data are not linked. Strict Exclusion means that, if after reducing there is no data available, the user will not be able to access the document. If all users had records available, then Strict Exclusion show only the records corresponding to them, instead of everything.
Actually, the user and password it keeps you asking should be the one corresponding to section access, and not the Active Directory credentials. You can easily check this if after a failed document login the user is still able to see the documents in the Accesspoint (in the webpage, above right will appear "LOGGED IN AS:" and the username in the form DOMAIN\username.
Perhaps obvious but are you reducing data (keeping possible values) using the same exact field you are using in the section access?
Hope this helps
I think it's worth noting that in addition to the above, the "*" in section access doesn't mean "all possible values" but "all listed values within the fieldname in section access". Assume the following:
STAR IS *; SECTION ACCESS; LOAD * INLINE [ACCESS, USERID, PASSWORD, REDUCTIONADMIN, ADMIN, ADMINUSER, USER, USER, *]; SECTION APPLICATION; DATA:LOAD * INLINE [REDUCTION, VALUEA, 1B, 2];
When opening on the Desktop, the ADMIN will be granted access even with strict exclusion, because of the ADMIN value in the ACCESS field, while USER will not, because the "*" in the REDUCTION field lists no values, actually. If the document is opened in server, none of them will be granted access, because ACCESS field is not taken into account, so the ADMIN user is now a USER access.
Hope that helps
Problem resolve a few weeks ago, but just now I had time to report it. The problem is Section Access works fine if you do not load the access table from a resident table, if you do, it will not work. Maybe is a bug, maybe is a natural behavior, but by putting the load table directly after the section access made my code to work also in access point.