Initial Selection Based on Section Access in QV Server (Hide tabs)

[Anonymous]

Hello,

I've implemented one of the simpler Section / Sheet access examples I found on here. It appears to work on desktop but not on Server.

I've set the Document Properties to Lock the NTNAME (As USERID) field and reduce Sheets (Conditionally Show) based on Section Access.

Section Access;

/* CHANGE THE NTNAME, USER, OMIT VALUES in xls file TO REFLECT YOUR OWN USERS */

SECURITY:

LOAD ACCESS,

     NTNAME,

     USER,

     OMIT

FROM

BillingUserSheetAccess.xls

(biff, embedded labels, table is UserRoles$);

//

///* CHANGE THE NTNAME AND USER VALUES TO REFLECT YOUR OWN USERS */

Section Application;

LOAD NTNAME,

USER as ROLE

Resident SECURITY;

inner Join

//SHEET_ACCESS:

LOAD USER as ROLE,

     Main as SH01,

     [Main - Management Team] AS SH06,

     Contribution AS SH02,

     [Contribution - Management Team] AS SH07,

     Deployment AS SH03,

     Profitability AS SH04,

     [Revenue - Management Team] AS SH08

FROM

BillingUserSheetAccess.xls

(biff, embedded labels, table is SheetAccess$);

Rename field NTNAME to USERID;

DESKTOP:

QV SERVER:

Any help would be much appreciated!

Thanks,

Channing

[Anonymous]

Steve,

I commented the section access out so I could see what data was being produced with that script. I included the OSUser() to see if NTNAME and OSUser() would match once deployed on the server.

NTNAME was QVSERVICEAGENT and OSUser was cworkman.

Omit is there because I must hide fields and that is working perfectly fine. The issue is the fact that my distribution server isn't recognizing the User logging in.

Thanks,

Channing

[stevedark]

Hi Channing,

The OSUser at reload time is of no relevance to Section Access, as long as that account has the rights to open and reload the app - you will get a QMC fail if this is not the case.

OSUser when an app is open on the server will be the AD account that is used to log in to the web server.  On a local network this will usually pick up directly from the machine login, and therefore be the same as it is when the app is open in Desktop.

I don't understand what you mean by the Distribution Server not recognising the user logging in.  This server just reloads and saves the document.

Do you still have users who are unable to open the document post reload?

Have you tried going into the app as them when the Section Access has been commented out and seen what they have as their OSUser()?

Steve

[Anonymous]

Steve,

If I remove section access and strict exclusion I get the right User(). However, if I keep strict exclusion it won't allow the MgmtTeam and Owner users. My name (cworkman) works with Section Access and Strict Exclusion or Section Access alone. I keep coming back to Strict Exclusion as the issue.

Is there something I'm doing wrong on the Server side? (Adjust QMC)

Thanks,

Channing

[stevedark]

Are MgmtTeam and Owner users or groups?  Have you tried using individual users instead of groups?

With the Section Access part commented out, does the section access table link correctly to the rest of the data on the field you are matching on?

When you select MgmtTeam does it select the correct matched data (unless you are using *, in which case it won't).

Are all field names being matched by Section Access upper case? Are all field values in these fields also in upper case?

If you create a text box with the following expression in, what does it return when you log in, and what does it return with MgmtTeam logs in?

=maxstring({<NTNAME={'$(=Upper(OSUser()))'}>}NTNAME)

Hopefully we will get this fixed soon for you.

I can't see that there is anything that will need to change on the QMC side, if it works for your user and the other accounts are also users.

Steve

[Anonymous]

Steve,

I have it working the way I'd like it to now, but I think I've definitely executed a work-around.

So, I left strict exclusion unchecked, but Section access blocks the appropriate data dependent on the User (My data is hidden safely away).

However, I've renamed the fields in my SheetAccess table so that nothing is excluded (all users all roles and their specific flags). I then set up a trigger that selects the User from that table dependent on the User logged in and locked the field upon Opening.

This hides the appropriate sheets while maintaining section access's data exclusion.

Does this make sense and if so is this a "safe" way to go about things?

Thanks,

Channing

[stevedark · Accepted solution]

Hi Channing,

The main thing to ensure is that rows are removed using Section Access, so that data is secure.  Manipulating the UI, by hiding sheets etc., doesn't requite to be part of Section Access, and a data island with this will work fine.

I would be wary of not having Strict Exclusion checked - in what way does it fail if this is ticked?  Sometimes you need to add extra rows to your Section Access table so that all permutations exist in that table - to define the scope of what the * symbol refers to.

Generally, I would look to avoid triggers.  From what I understand of why you are using these, a bit of Set Analysis may work better.  Something like this on the Sheet Visible property:

=maxstring({<SheetUser={'$(=Upper(OSUser())))'}>}SH03Allowed) = 'Yes'

This way you don't need to apply the selection with the trigger and there is no risk of someone clearing a selection, or that selection appearing in the Current Selections box.

Steve

[Anonymous]

Steve,

My issue is any user not assigned as an "Admin" getting completely locked out when Strict Exclusion is checked. Thank you for the tip on Set Analysis. I can see how that would be more effective for the UX.

Thanks,

Channing