⟵ hearthere ⟶
  • Quick start
  • Install MIT
  • Install PRO
  • Updating
  • Optimization
  • Update v4-v6
  • Backups
  • Console utility bin/totum
  • Basics for users
  • Interface and Layout
  • Tables and their parameters
  • Prefilter
  • Fields and their parameters
  • Syntax
  • Code, actions, formatting
  • Relational relationships
  • Calculation order and calculation units
  • Auto-complete calculations and timing
  • Duplicate rows and cycles
  • Comparisons
  • Functions
  • Debugging
  • Print and CSV
  • API
  • Roles and users
  • Tables of Roles and Users
  • Role Creator
  • Role-based Access to Tables
  • Role Settings in Fields
  • Priority of Overlapping Accesses
  • Field Visibility Only for Creator
  • Access to Cycles
  • Type of Access to Cycles
  • Tables with One Cycle
  • Role and User Locks in Codes
  • Required System Users
  • Password Recovery via Email and Password Guessing Lock
  • Enabled/Disabled for Users
  • User Management Access
  • SUDO Users
  • Favorite Tables
  • Dashboards on the Main Page
  • Redirect Table
  • Notifications
  • Scheduled Actions
  • System tables
  • Trees
  • Anonymous tables
  • External Forms
  • Exporting and importing tables
  • [PRO] MeiliSearch
  • [PRO] Databases
  • [PRO] Custom CSS
  • [PRO] Custom docs
  • [PRO] LDAP AD
  • [PRO] File versions
  • [PRO] List-unsubscribe
  • [PRO] Dynamic fields
  • [PRO] Only Office
  • [PRO] Auth Tokens
  • [PRO] 2FA
  • [PRO] Superlang
  • [PRO] Daemons
  • [PRO] Profiler
  • Connecting functions
  • [SRV] Installation and Connection
  • [SRV] Export, PDF, Upload, and Preview
  • [SRV] XLSX/DOCX Generators
  • Roles and Users

    Tables of Roles and Users

    Located in System TablesAccessesUsers, Roles:

    Users and Roles

    • Roles — specified in tables and fields and determine the access level. Roles Table

    • Users — have logins and passwords for authorization. Roles are assigned to a User, which determine their access level. Users Table

    Role Creator

    Has id=1. All created tables are automatically added to it for modification. Sees hidden fields and the system settings layer.

    Role-based Access to Tables

    Role-based access to a table is edited in the table settings:

    Roles in Table

    Role Settings in Fields

    Priority of Overlapping Accesses

    If a user is assigned multiple roles that define access to the same tables differently, modification and display will take priority over reading and hiding.

    Field Visibility Only for Creator

    Visible Only to Creator

    Click here to quickly disable the system settings layer and fields visible only to the Creator:

    Switch

    Access to Cycles

    Type of Access to Cycles

    The cycle table has a mandatory technical field User Access (creator_id) upon creation. By default, the user who created the cycle is recorded there.

    Based on this field, the creator (owner) of the cycle is determined. It can be changed manually or by codes, and multiple owners can be selected in it.

    Further access to cycles will be carried out according to the table setting type of access to cycles.

    When it is necessary to create a hierarchical access structure, the fields Supervisor (boss_id) and Access to User Cycles (add_users) are used.

    The Supervisor gets the creator's access to their subordinates' cycles. Similarly, a user gets access as the cycle creator to the cycles of users selected in add_users.

    Tables with One Cycle

    Rarely used special mode of operation that allows the user to create only one record in the cycles table.

    If it does not exist, then when the table with one cycle is first opened, this record will be created automatically.

    To prevent access to other users' cycles, it is mandatory to set the Cycle Access Type to No one can see except the creator.

    Role and User Locks in Codes

    In action codes, formatting, or selects, you can process the current user's role and user id:

    • $#nr — list of user role ids.

    • $#nuid of the user in the Users table.

    f1=: setFormat(condition: $#nr = 3; block: true)
    

    Required System Users

    • admin — default user with the role creator.

    • cron — technical user from whom scheduled tasks are executed.

    • service — technical user from whom user password recovery and changes are performed.

    • anonym — user from whom access to anonymous tables is performed.

    Password Recovery via Email and Password Guessing Lock

    Several settings related to users are moved to the System TablesMainSettings and CronSettings table:

    • Lock Time — the time within which a login-password must be entered incorrectly to lock this login for the same time.

    • Number of Attempts — the number of incorrect attempts within the lock time period.

    If you need to urgently unlock a locked user — this can be done from the server console with the command bin/totum schema-user-unblock username -s=schema_name (replace schema_name with your schema name, default is totum).

    API users who connect to the system frequently clutter the authorization log table, slowing down subsequent authorizations as it increases verification time. For such users, there is a mechanism to disable logging of authorizations in the DB and blocking on incorrect password entry. The ttm__off_auth_log field in the users table.

    • Password Recovery via Email — if true, users will be able to request password recovery via email.

    Password recovery will only be possible if the user has an email set. Password recovery via email sends from noreply@host. SMTP settings described in emailSend are also required.

    Enabled/Disabled for Users

    Disabling a user blocks their authorization in the system and closes all existing sessions upon the next change in the open table or its update.

    User Management Access

    A user assigned this parameter in the Users table gains access to tables related to user management and can also change access for users not related to technical and Creators.

    A user with this access cannot assign the Creator role to another user or themselves.

    They also cannot assign a sudo-user to themselves or another user.

    User Access

    SUDO Users

    Allows switching between users, except for users with the creator role, and performing actions on their behalf in the system.

    An action performed in sudo mode is indistinguishable in logs from an action performed by the user themselves.

    Favorite Tables

    Users can assign themselves favorite tables, which will be displayed in the tree when navigating to the main page by clicking on the schema icon. Favorite tables can also be selected for a role — they will then be automatically assigned to the user upon creation with that role.

    Favorite tables for a specific user are assigned and changed in the System TablesAccessUsers table.

    Dashboards on the Main Page

    In the System TablesAccessRoles table, you can assign a temporary table for a role, which will be displayed on the main page.

    Multiple tables can be selected — they will be displayed in tabs in the order of their sort.

    Redirect Table

    In the roles table, in the redirect_table_in_roles field, you can select a table to which an automatic transition will be made upon login to the system.

    If a user has multiple roles with different redirect tables — the one with the highest sort priority will be chosen.

    You cannot select tables within a cycle!