Ryan, It looks like you set this up as a data restriction for a single security group. If you are testing this while logged in as yourself (as an admin), the restriction will not affect you.
I think a global data restriction would be easier to manage, but if you want to use the group-based restriction, you should also add the restriction to MAXEVERYONE since your supervisors also belong to that group. If you have a test user account, you could put that test user in your supervisor group only (so the test user is in the supervisor group and MAXEVERYONE but no other groups), then add the data restriction to MAXEVERYONE, and then log in as your test user to see if the restriction applies. The downside to using the group-specific data restriction is that you'd have to restrict other groups to which the supervisors might belong unless you want membership in those other groups to "lift" the restriction.
Alternatively, you could remove the restriction from the supervisor security group and set it up as a Global Data Restriction (from the Select Action menu). If you try it this way without the conditional expression, then after you log out and log back in again, you should see the checkbox is read only, even for you as an admin. You could then try adding the conditional expression to limit the restriction to users who are supervisors and not also in MAXADMIN or other groups who should be able to publish their queries. After logging out and logging back in again, you should be able to make your queries public again (as an admin), but users who are supervisors and not admins should still see the checkbox as read-only. You could check that with a test user that is only a member of the supervisor group. I think this approach will be easier to manage because you will not have to keep track of multiple security group restrictions; the logic will just be in one spot, and you will be restricting users because they are supervisors, even if they also happen to belong to groups that you are not trying to restrict (other than the admin or superuser groups that get excused from the restriction in the conditional expression).
------------------------------
Nancy Lerner
Brio Consulting
------------------------------
Original Message:
Sent: 01-07-2022 13:07
From: Ryan Sheeler
Subject: Security Group app Permissions - public Queries (Queries app)
Here is my security group setting (Attribute Restriction) for Supervisors. I have made ISPUBLIC Read Only and saved it. But when I go into Work Order Tracking and Save Query I can still select the Public checkbox which isn't what I want. I'd want it grayed out altogether so users in that group can't select it. Do I need the Condition or not - and is that why it isn't working?
Original Message:
Sent: 01-07-2022 12:47
From: Nancy Lerner
Subject: Security Group app Permissions - public Queries (Queries app)
When creating the conditional expression, you may want to keep the "not in" logic so that you don't inadvertently turn off the query publishing functionality for users who are members of other groups besides the Supervisor group. For example, you may have admins or super-users who are also part of the supervisor group. So perhaps try a condition like:
:USER not in (select USERID from GROUPUSER where GROUPNAME in ('MAXADMIN','<Exalted_Superusers>')) and :USER in (select USERID from GROUPUSER where GROUPNAME = '<Supervisors>')
This would make the Public checkbox read only for your "real" supervisors while allowing access to the checkbox for those users who happen to be in the supervisor group but are actually admins or some type of super-user.
------------------------------
Nancy Lerner
Brio Consulting
Original Message:
Sent: 01-07-2022 12:23
From: Ryan Sheeler
Subject: Security Group app Permissions - public Queries (Queries app)
Hi Nancy,
For now I just want to restrict them from making Queries public in Work Order Tracking for a single group (ex. Supervisors). I think your second example (B) is more along the lines of what I'd like to do.
------------------------------
Ryan Sheeler
Original Message:
Sent: 01-07-2022 12:04
From: Nancy Lerner
Subject: Security Group app Permissions - public Queries (Queries app)
Ryan, are you sure you want to allow users to make their queries public in all other applications? This could lead to a lot of clutter. But if you really want to leave the "is public" option open everywhere but WOTRACK, you could either:
A) Add the sig option from the library XML to all applications where it is missing and grant it to MAXEVERYONE in all other applications; then grant it only to selected security groups for WOITRACK, or
B) Remove the sig option from the Library and instead create a global data restriction (for an attribute restriction) in Security Groups application. The object is QUERY, the attribute is ISPUBLIC, the application would be WOTRACK, and the type should be set to READONLY (to allow users to see the value in their Saved Query table even thought they cannot check the box when they save a query). The restriction should be set to reevaluate, and then you can set a condition that limits the restrictions to users who are not members of the MAXADMIN security group or other "superuser" groups that you might want to grant "query publication" rights. For example, the conditional expression could be :USER not in (select USERID from GROUPUSER where GROUPNAME in ('MAXADMIN','Exalted_Superusers'))
If you want to limit the ability to publish queries in all applications, you could use the global data restriction and just not specify an application. If you want to manage the ability to publish on an application-by-application basis, then the better approach is the use of the Sig Option, which you will need to create in all of the applications but then can decide which groups get access on an application-by-application basis.
------------------------------
Nancy Lerner
Brio Consulting
Original Message:
Sent: 01-06-2022 16:24
From: Ryan Sheeler
Subject: Security Group app Permissions - public Queries (Queries app)
Further clarification. I talked with some users and they actually use Work Order Tracking to get at Queries - via the Save Query dialog. I told them that is the library.xml which affects some global settings. I tried the following XML edit which worked well, expect that it took away the Public checkbox under Save Query in all of Maximo. Of course that's not what I want. I'd like to be able to just do it for Work Order Tracking only.
https://www.ibm.com/support/pages/placing-sigoption-public-checkbox-saved-queries
Original Message:
Sent: 01-06-2022 09:52
From: Ryan Sheeler
Subject: Security Group app Permissions - public Queries (Queries app)
Hi all,
in Maximo Security Group application permissions, is it possible to set the Queries app so that a given group can create Queries but not make them Public. My group is exploring this and I was just wondering if this is possible. Many thanks.
#Administration
#Security