osconf
| This page was automatically generated from the database schema dump and may be incomplete or incorrect. |
Records of the user-related data, one row per user, type and name.
All UserData jobs of the dms engine work on this table: verified for
dms.SetUserData, dms.SetUserDataAsString,
dms.GetUserData, dms.GetUserDataAsString,
dms.GetUserDataNames and dms.DeleteUserData.
dms.GetConfValues reads the table by type. Measured on enaio® 12.0.
1. Columns
| Name | Type | Length | Description |
|---|---|---|---|
|
|
— |
User ID ( |
|
|
— |
|
|
|
— |
User-related data type (e.g. |
|
|
2147483647 |
Value of the record. dms.SetUserDataAsString writes UTF-8 with byte-order mark ( |
|
|
— |
Primary key. Returned as |
|
|
— |
|
|
|
100 |
Record name (parameter |
2. Profile distribution
A user with an assigned profile (benutzer.profil = ID of the
profile user; the profile user itself has profil = 0) only receives the user-related data of
the profile user when the profile is distributed in the enaio administrator. Assigning the profile
alone, e.g. via mng.SetUserAttributes, and a login do not
change osconf.
Observed when distributing:
-
The types the profile user holds are copied (measured:
2,3,4,59). The copies are byte-identical, have an empty name and carry the ID of the profile user inosconflink. -
The user’s own rows of these types are replaced; for type
2the copy is added in addition. Other types stay untouched. -
The distribution goes to all users with this profile. Afterwards
benutzer.geaendert=0. -
The reference in
osconflinkis kept when the user changes the row, and also when the profile is removed. -
There is no fallback to the profile: once the copy is deleted, dms.GetConfValues returns no record for this type.
-
The linked type 2 row is invisible to dms.GetUserData, dms.SetUserData and dms.DeleteUserData, but dms.GetConfValues returns it. The cause is open.
It is open which job the enaio administrator uses to write the copies.