The CAS Table State Management, is a functionality available to the SAS Administrator. The CAS table state management enables you to manage the import and load of source files as well as the unload of tables from memory in caslibs. It is made available to the SAS administrator using predefined sample jobs.   This article will show how these jobs can be made available to a normal user, so that he can take advantage of the functionality provided by these jobs. Topics we will look into Introduction to the sample jobs Make a copy of a sample job Create new jobs from a template Considerations Introduction to the sample jobs There are 3 Table State Management jobs available: Sample: Import cas-shared-default Public data This job demonstrates settings that import all CSV, SAS7BDAT, and EXCEL files in the Public caslib to SASHDAT files in the same caslib. Sample: Load cas-shared-default Public data This job demonstrates how to load all SASHDAT files found in the Public caslib. Sample: Unload cas-shared-default Public data This job demonstrates how to unload all loaded CAS tables in the Public caslib that have not been accessed within the past 7 days.   These job are available to the SAS Administrator in a read-only mode. In order to use them, the SAS Administrator will make a copy of one of these jobs and can then edit the options and settings for the respective job.   We will show how any user can take advantage of the functionality provided by these jobs to import, load and unload data to a caslib without writing any code.   Here we see where the SAS Administrator can find them.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Below we can see the options and settings (partial list) for the Sample: Load cas-shared-default Public data job.     Since this is the original sample job, there is no way for us to edit this information. To actually work with one of the sample jobs, the SAS Administrator needs to make a copy.     Make a copy of a sample job   To make a copy of the job, the SAS Administrator uses the context menu on one of the sample jobs and choose Copy. We can provide a name and a description for the new job. By default the text "_copy" is added to the end of the name. For our example I changed the name of the caslib in both the name and description and removed the "Sample:" from the name.     The copy of this job is only available to SAS Administrators.   Let's compare the two jobs. They are jobRequest objects, so we can use the sas-viya job requests CLI to have a closer look.   First the SAS Administrator needs to find the id of a jobRequest object. He can do this either by displaying the properties, or he can use the command below. Please be aware that the eq function is case sensitive by default. To make the function ignore the case use this filter definition: --filter 'eq($primary, name, "sample: load cas-shared-default public data")'   OID=$(sas-viya --output json job requests list --filter 'eq(name, "Sample: Load cas-shared-default Public data")' | jq -r '.items[].id')   Likewise the SAS Administrator does this for the new job   NID=$(sas-viya --output json job requests list --filter 'eq(name, "Load cas-shared-default Finance data")' | jq -r '.items[].id')   The SAS Administrator  has now the id's of the original job (OID) and the new job (NID). With this information he can store the definition of a job in a JSON file and compare the contents.   sas-viya --output json job requests show --id $OID > ojob.json   sas-viya --output json job requests show --id $NID > njob.json   Now let's compare the two files using icdiff (might not be installed by default) or you preferred tool to compare files.     We can see the main differences being the user that created/modified the job, id, timestamp information, name and description. The highlighted text shows whether it is a sample job, or a copy of a job. This is what determines if we can edit the options and settings for this job.   With this knowledge we can make a copy of a job without going through the GUI. Either using an editor and make the changes or using the functionality provided by the jq command, that allows us to manipulate a JSON file. Here is an example:   jq --arg keyname sampleJob --arg value copy --arg newname "Load name caslib" --arg newdesc "Load name caslib" '.properties |= map(select(.name == $keyname).value = $value) |.name |= $newname |.description |= $newdesc' ojob.json > load-name-caslib.json   This command changes the text for "value": "true" to "value": "copy" and provides a generic value for name and description. You can verify the content of the new file using:   jq . load-name-caslib.json   We now have a json file that can be used to create new job. In this new job we will be able to edit the options and settings, like caslib, which type of files to load etc.   Note: All the sas-viya commands have to be run as an SAS Administrator because of permissions.   Create new jobs from a template The JSON file created before can now be used as a template to create new jobs using this command: sas-viya job requests create   This command supports two options: --file-in Specifies the input file that contains the details about the job-request definition. --folder-id (optional) Specifies the ID of the parent folder in which to save the job-request definition.   Providing a folder id, has several advantages like: you can rename a job, all users that have the appropriate permission for the folder content can work with this job.   The information on user created/modified, id, timestamp information still present in the JSON file is ignored when creating a new job. To get the id of a folder and store it in a environment variable we use this command:   Public_ID=$(sas-viya --output json folders show --path /Public | jq -r '.id')   We are now ready to create a new job and store it in a folder.   sas-viya job requests create --file-in load-name-caslib.json --folder-id $Public_ID   Although the job is a member in a folder, in order to edit the settings of the job you go to SAS Environment Manager - Jobs & Flows - Scheduling tab. When displaying the properties of a job we can go to the Arguments tab and see the edit icon, that allows us to change the caslibs, filter (which files to process) and other settings.     See the Job Options for more details on what can be set.   From the Jobs and Flows page we can now schedule a job so that it runs on regular intervals. Please note, only the user that executed a job will see the result of his job. The SAS Administrator will see all the jobs from all the users.   Using this method more jobs can be created for additional caslibs.   Considerations The user executing one of the Table State Management jobs needs the appropriate permissions on the caslibs used by the job. Import and Load jobs need the following permissions: ReadInfo, Select, LimitedPromote, Promote, CreateTable, DropTable, DeleteSource. The Unload job needs the following permissions: ReadInfo, Select, DropTable   If a group of users need to maintain a job and look at the results of the executions see Using a Group-Managed Service Account for more information.   We can use the jobRequest API to create jobs. Here is a basic example using a SAS program.   Summary By default the Table State Management jobs are only available to the SAS Administrator. We have seen how the SAS Administrator can provide this functionality to normal users. This allows them to take advantage of the functionality provided by these jobs to load, import or unload data without any coding.   Additional reading: SAS Viya jobs object model explained to better understand what a job is.   Find more articles from SAS Global Enablement and Learning here. ... View more

In a recent question on communities.sas.com, someone asked whether it is possible to limit the users or groups a user can see. The API for the identities service, that provides this information is not public. However any user could make use of the sas-viya CLI to list this information. Depending on the setup, phone numbers or addresses etc. might be shown.  This might not be something you want.   In this post we will look at configuration settings that allow an administrator to control what non-administrative users can see when they make use of the sas-viya CLI identities plugin to list users and groups or show details about a user.     Topics we will look into   Overview of properties Example for each configuration property Are there any side effects How to set the properties using the sas-viya CLI     Overview of properties   The following table, from the documentation,  shows the configuration properties of the Identities service that will change what the non-administrative users can see. These options are available since LTS 2023.10. Note that by default none of the properties are enabled.   Property Default Value Definition endpoints.secured.groups: not enabled by default When enabled, limits non-administrative users’ Read access for groups. endpoints.secured.members: not enabled by default When enabled, limits non-administrative users’ Read access for group members. endpoints.secured.memberships: not enabled by default When enabled, limits non-administrative users’ Read access for group and user memberships. endpoints.secured.users: not enabled by default When enabled, limits non-administrative users’ Read access for other users.   You can find these settings in the SAS Environment Manager -> Configuration page     Please note, there is a new checkmark icon beside the pencil icon that indicates whether the default is used or it has been modified (no checkmark icon).     Example for each configuration property   We will look at the effect each property has.   Please note: there is a delay from enabling the property to it being applied, allow for 10-20 seconds before checking the result.     Impact of endpoints.secured.users   When this configuration property is enabled a non-administrative user will only see itself when asking for a list of users.   See here a screenshot with disabled / enabled results. The sas-viya command shown in the screenshots uses the profile eric (-p eric), this means all the commands run as user eric.     When enabled you can no longer show detailed information for another user. Example:     By enabling the endpoints.secured.users property, you prevent non-administrative users from seeing details of other users, or even that other users exist. In the above example we can see that eric can view the user eric (himself), but he can not view the information for another user (christine). This might already be all you need.     Impact of endpoints.secured.groups   When this property is disabled (default) a non-administrative user will see all the groups when using a command like this:   sas-viya -p eric identities list-groups   When this property is enabled only the groups the user is a member of, either directly or through group membership, are displayed:     In the example above the user eric has the following group memberships:       Impact of endpoints.secured.members   So far we have seen the impact of the endpoints.secured.users and endpoints.secured.groups properties. The user can still list all members of a group he belongs to. Example:     When endpoints.secured.members is enabled, the same command will only list the user that makes the request:       Impact of endpoints.secured.memberships   The sas-viya CLI identities plugin has a command list-memberships that allows to either provide a user (--user-id) or a group (--group-id) to list their memberships. When this property is enabled (all others are disabled) a non-administrative user can only see groups:   of which the current user and the given user (--user-id) are both members of which the current user and the given group (--group-id) are both members   Example:   The first command is run as eric requesting to see memberships of user delilah. Only the group NestedGroup01 is displayed since delilah is a direct member of NestedGroup01 and eric is a member of NestedGroup02 which is a member of NestedGroup01. The second command is run as SAS administator so all groups where delilah is a member of are displayed.     In other words, when the endpoints.secured.memberships property is enabled, the current user can only see groups which a named user or group is in, where the current user is also a member of those groups. So if the named user or group is a member of one or more groups that the current user is not a member of, the current user cannot see that the named user or group is a member of those other groups.     Are there any side effects   Will the above settings have any side effects. Yes they will! Below are some examples of functionality impacted.   Can I still share SAS Content objects like a Visual Analytics report? Yes this is possible. Can I still distribute a Visual Analytics report to other users? No! Since you no longer can read specific user information for other users, it is not possible to read for instance the email address from another user, so you will get an error as shown below.   This is not a complete list of side effects. This is the reason, why these configuration properties are not enabled by default. You have to decide what will work for you and which side effects you can live with, when enabling these configuration properties.     How to set the properties using the sas-viya CLI   Configuration properties can be set using the Configuration page in SAS Environment Manager. But often it is desirable to do this using a scipt. See here for the steps necessary to do this.     Read the mediatype for what we want to change and store it in an environment variable   MEDIATYPE=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["metadata"]["mediaType"] ')     Next create a JSON file with the properties we want to change   tee /tmp/update_identities_settings.json > /dev/null << EOF { "name": "identities configurations", "items": [ { "metadata": { "isDefault": false, "mediaType": "${MEDIATYPE}" }, "endpoints.secured.users": true, "endpoints.secured.groups": true, "endpoints.secured.members": true, "endpoints.secured.memberships": true } ] } EOF     Update the configuration instance   sas-viya configuration configurations update --file /tmp/update_identities_settings.json     Verify the settings   CFG_ID=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["id"] ') sas-viya configuration configurations show --id $CFG_ID   The output looks like this:   sas-viya configuration configurations show --id $CFG_ID id : 0da33450-35e0-4b23-bbe1-3fa78a042ab1 metadata.isDefault : false metadata.mediaType : application/vnd.sas.configuration.config.sas.identities+json;version=5 metadata.services : [identities] cache.cacheRefreshInterval : 12h cache.enabled : true cache.providerPageLimit : 1000 defaultProvider : local endpoints.secured.groups : true endpoints.secured.members : true endpoints.secured.memberships : true endpoints.secured.users : true identifier.disableGids : false identifier.disallowedUids : 1001 identifier.generateGids : false identifier.generateUids : false identifier.homeDirectoryPrefix : /home     Summary   By default any user can get a list of all users and groups. Any user can display the details about another user, or list the members of a specific group. By enabling the named properties the administrator can restrict the access for a non-administrative user to only himself and the groups he is a member of (direct or indirect). Some functionality within SAS applications might be affected.     Find more articles from SAS Global Enablement and Learning here. ... View more