Full manual diffs (L15, C20, E30, L25, J40, C10 §2, L10, P10, P11, J20, C30, P20, R40, E10) and read-only checks on the shared R1.05 test server. Skills and summaries moved to R1.05; new skill pytools (IM 36K10P40) from docs (no Python on the test server). Issues ISS-132..181; corrections to version-differences (E10, E30, P11, dss_ath_grp_u0104); C10 summary lists the 3 new authorization actions; r105-verification V10-V17. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6.3 KiB
| task | version | source | status |
|---|---|---|---|
| Create, check and remove authorization groups and users with quick load | R1.05 (first written for R1.03) | IM 36K10C10-01EN 5th ed. (Feb. 2026) §2.4, §2.5; IM 36K10L45-01EN 5th ed. §4.2.2 (API key); data dictionary (`dssqld -f`); practiced on the test system 2026-09-30 | verified on R1.03 (2026-09-30, 2026-10-06); on R1.05 the USER_DF, USER_VAL, AUTH_ACTION_DF definitions were checked identical and AUTH_GROUP_DF extended to 250 actions, AUTH_ACTION_DF and SCHEME_DF exported read-only (R1.05 test server, 2026-10-09); loading users and groups not re-tested on R1.05 (shared server, no user or group changes) |
Authorization groups and users (quick load)
Engineering Module equivalent: Authorization → Authorization groups / User → Add.
Datasets: AUTH_GROUP_DF (groups), AUTH_ACTION_DF (allowed action names), USER_DF
(users). Works from a normal prompt while CI Server is running. Use short relative file
names (cd to the folder first): long absolute paths are cut (ISS-020).
List what exists
dssqld -e groups.qli -d AUTH_GROUP_DF -c -l groups.lst
dssqld -e users.qli -d USER_DF -c -l users.lst
dssqld -e actions.qli -d AUTH_ACTION_DF -c -l actions.lst
Installed on R1.03: groups SYSTEM_MANAGER, ENGINEER, OPERATOR, GUEST; users ADMIN,
ADMINE, OPER, CI_NO_LOGIN_OPCUAS. Passwords export as ****. R1.05: the same four
factory groups (verified 2026-10-09); AUTH_ACTION_DF has 203 actions (R1.03: 200).
Group
Required: NAME. Actions go in ACTION_NAME_1, ACTION_NAME_2, … (up to ACTION_NAME_250 on
R1.04 and later, 200 on R1.03) and must be names from AUTH_ACTION_DF (e.g. ITEM_READ,
ITEM_MODIFY_VALUE, SECTION_BLOCK_UNBLOCK, ALARM_CURRENT_ACK). New on R1.05:
UA_MAPPER_PROJECT_INSERT, _MODIFY, _DELETE (dataset UASERVER_MAPPER_DF, OPC UA
Information Model Mapper; no _READ action exists). The RESTful API, pyTOOLS and API keys
have no actions of their own: a REST or Python session has the rights of the user it logs on
as (ISS-146). A group with more than 200 actions cannot be moved back to R1.03, which has only
200 action fields. Example (examples/CI-Eng-Sample/08_auth_group_df.qli):
@FIELDS
NAME,DESCRIPTION,ACTION_NAME_1,ACTION_NAME_2,ACTION_NAME_3,ACTION_NAME_4
@AUTH_GROUP_DF
"CIENG_VIEWER","CI-Eng-Sample read-only viewer","ITEM_READ","SECTION_READ","ALARM_CURRENT_READ","ALARM_CHRONO_READ"
User
Required: NAME (≤ 32) and AUTH_GROUP (an existing group). Optional: DESCRIPTION,
PROCESS_AREAS (e.g. "1-999"), LOGOFF_TIMEOUT (minutes, 0–999), INITIAL_DISPLAY,
LOCALE, ENTERPRISE, LAYOUT, playback fields. Password: without a PASSWORD field the user
is created without any password set and every logon fails with DSS-E-UNK_USER Unknown user
name/password combination; set the password in the Engineering Module (the user does this, not
Claude). A user with an empty password is created by giving PASSWORD "" explicitly
(tested 2026-10-06, sample user CIENG: logon on desktop and web). Template:
@FIELDS
NAME,DESCRIPTION,AUTH_GROUP,PROCESS_AREAS,LOGOFF_TIMEOUT
@USER_DF
"<USER>","<description>","CIENG_VIEWER","1-999",15
Defaults filled in on import (seen): display authorization level 999, language System, playback HMI Client dependent / No, merge priority 1. Changes take effect at the user's next login.
API key (RESTful API, R1.04 and later)
The RESTful API needs, besides the user's name and password (HTTP Basic), an API key of that
user in the x-api-key header (IM 36K10L45 §4.2; skill data-access). The key is made in the
Engineering Module: Authorisation › Users, right-click the user, Add API Key: key name
(user name plus a hint that it is a RESTful key), description (≤ 79 bytes), API Type
RESTful API, Request API key. One key per user; the manual says requesting it again gives
the same key, so deleting and re-requesting does not replace a leaked key — change or
remove the user instead (ISS-151, not tested).
Dataset API_KEYS_DF (verified definition, R1.05 2026-10-09): NAME = <USER>:<KEY NAME>
(≤ 64, upper case), USER_NAME (must exist in USER_DF), API_KEY_NAME, DESCRIPTION,
API_TYPE (only RESTful API). The key itself is not a field of the dataset, so it
cannot be exported or loaded with quick load; full exports skip API_KEYS_DF (ISS-118).
Create keys again on a new or restored system. Claude never reads, writes or stores API keys.
Check and remove
Filtered export (@SELECT, see system-management task export-dataset.md):
@SELECT
'NAME = "<USER>"'
@USER_DF
Remove users first, then the group, in one NAME-only file (dssqld -r):
@FIELDS
NAME
@USER_DF
"<USER>"
@AUTH_GROUP_DF
"CIENG_VIEWER"
Test system (R1.03, 2026-09-30)
Group CIENG_VIEWER and user CIENG_TEST (no PASSWORD field, logoff 15 min) loaded with 0
errors, exported back as defined, then removed (1 + 1 removed, 0 errors). Logon was not tried;
such a user cannot log on (see User). The group is part of CI-Eng-Sample.
Sample user (R1.03, 2026-10-06)
examples/CI-Eng-Sample/08b_user_df.qli: user CIENG, PASSWORD "", factory group OPERATOR,
LAYOUT CIENG_Operator, INITIAL_DISPLAY CIENG_Overview; logs on to that layout on the desktop
and on the web (no ?l= needed). Removal (85_remove_auth_group_df.qli) removes the user before
the group.
Log out all sessions of a user before removing its group: while a session is open the group
is still referenced in USER_VAL and dssqld -r fails with DSSP-E-NODEL … in dataset
USER_VAL; logging out did not free it at once, and a retry in that state stopped the process
DSSSDA03 (DUR-F-BAD_SIZE, Negative size not allowed; later requests failed with
DUR-F-UNKNOWN_ATT) until CI Server was restarted (2026-10-06, ISS-073). After a restart the
group was removed without error. USER_VAL exports only its header (no way to list sessions).
On R1.05 this was not repeated (it stops a DSS process; the server is shared). USER_VAL
and AUTH_GROUP_DF keep the same relation, but the DSS processes are arranged differently
(ISS-117), so treat ISS-073 as still valid until it is re-tested on a separate system (ISS-152).
The same applies to the password behaviour of ISS-072 (USER_DF.PASSWORD unchanged): keep
giving PASSWORD "" or setting the password in the Engineering Module.