Users – login, roles and permissions

1. Account, role and user display

An account identifies who signs in. The username is used for login; the display name appears in the application and as a note author. A role contains permitted functions. Changing a role affects all accounts assigned to it.

Accounts are project-specific. The user object displays session status and provides login/logout; it does not create accounts itself or require a PLC address. Original screenshots show the German interface.

2. Insert the user object

Select Documents → Users. The example uses X = 20, Y = 130, width = 300 and height = 72. Assign area can place the object in a tab, collapsible area or scroll area.

“Benutzeranzeige / Name und Rolle” is the editor preview. “Keine Benutzer eingerichtet” in test mode means no project accounts exist yet. Open project settings to create them.

3. Create the first account

1. Open Settings → Manage users.
2. Click New. Enter username rainer and display name Rainer.
3. Use the management role, Administrator in this example, and keep the account enabled.
4. Set your own password of at least 10 characters.
5. Click Save. The account must then appear in the list on the left.

The first account must be active and able to manage users and roles. Rainer is already signed in after creation in this example. Close management, apply settings and save the project.

An empty password field on an existing account preserves its current password. A new account requires a password. Merely filling out the form does not save an account.

4. Sign in and out

1. Start test mode with F5.
2. Click Log out if necessary; the object shows that nobody is signed in.
3. Click Log in, select the active account and enter its password.
4. Confirm the login.

The display changes to Rainer / Administrator: display name above, role below. Without configured accounts, existing operating behavior is retained. This differs from being a signed-out guest after account setup.

5. View and edit roles

As an authorized user, open Settings → Manage roles. Select an existing role on the left to see its name and selected permissions. An empty name with unchecked boxes is the new-role form, not the Administrator permission set.

The screenshots show Beobachter (5), Bediener (15), Wartung (19), Projektierer (33) and Administrator (35 permissions). These counts describe this project state; actual checked permissions determine access, not the role name alone.

To edit, select a role, change its name or permissions and save. Click New first when adding another role. Scroll the permission list to see all entries.

6. Understand individual permissions

This reference explains all 35 permissions shown. Permissions are independent: editing recipes does not automatically permit transfer; creating notes does not permit marking them read. A workflow may require several permissions, such as editor access plus saving projects.

7. Create the Schichtbeobachter role

Click New, name the role Schichtbeobachter and select only:

• Open Play mode
• Open pages and detail windows
• Create notes

Save. The list now shows three permissions. This role can write notes but cannot change process values or mark notes as read.

8. Assign a second account

Open Manage users → New. Enter username beobachter, display name Schichtbeobachter, role Schichtbeobachter, enabled account and your own password of at least 10 characters. Save the account and project as an authorized user.

Sign Rainer out in test mode and sign in as beobachter. Display name and role name happen to match here, but are separate fields.

9. Test permissions

Starting with version 2.61.509, both note buttons visibly reflect permissions. Their appearance updates when users sign in or out.

The first image shows the signed-out state. Sign in as beobachter and create the note “Test der Rolle Schichtbeobachter”. Its author is filled from the signed-in account. After saving, the open count is 1. New note remains enabled; Read / open and the process enable control remain disabled. The screenshots demonstrate this behavior.

Missing operation permission is not a communication fault. Process values may still be displayed. An administrator with the relevant permissions can operate the corresponding controls for comparison.

10. Edit accounts, change passwords and disable accounts

1. With account-management permission, open Manage users and select the existing account.
2. Change its username, display name or role. Usernames must remain unique.
3. To change its password, enter a new one of at least 10 characters; otherwise leave that field empty.
4. Uncheck Account enabled to disable it, or check it again to reactivate it.
5. Save and save the project changes.

Disabling retains the account but prevents login. Delete removes the selected account. The currently signed-in account cannot be disabled or deleted. At least one active account must retain permission to manage users and roles.

These management procedures are described from the implementation. The screenshot sequence tests login and role permissions, not password changes, disabling or deletion.

11. Change role permissions or delete roles

Edit and save a role when its responsibilities change. All assigned accounts are affected. If only one person needs different access, create a suitable additional role and assign it to that account.

A role cannot be deleted while an account uses it; reassign affected accounts first. At least one role must remain. The program also protects the remaining active user/role management account from losing the permissions needed to administer access.

12. Automatic logout and saving

In Settings → Automatic logout, 0 disables the feature. Values 1 through 1440 specify minutes without registered user activity before logout in test mode. The example uses 0; automatic timeout was not demonstrated.

Save project changes with an authorized account. The practice role cannot save projects or use the editor. Sign in as Rainer again to continue editing.

Related guides: notepad and keyboard shortcuts.

13. Manage accounts and roles during runtime

Management is also available directly in Play mode, without switching to the editor. Access depends on Manage user accounts and Manage roles and permissions, not merely the role name Administrator.

1. Sign in as Rainer or another account with the required management permissions.
2. Open Benutzer / Rollen (Users / Roles) in the header. If the project already has a dedicated management button, use that button; the extra header button is then hidden.
3. With account-management permission, this opens user management. Use Manage roles to access roles when permitted. If the account only has role-management permission, the entry opens role management directly.
4. Select an account or role, make the change and click Save.
5. Check the status message about saving the project file.

Permissions and affected controls update in the running application. Role changes affect all assigned accounts. Runtime management attempts to persist changes directly to the project file. A message that the change was applied but the file could not be saved means the current change is effective but has not been saved permanently.

Protection rules still apply: the signed-in account cannot be disabled or deleted, and at least one active account must retain user and role management access. The image shows the runtime entry while an administrator is signed in. Editing within runtime management is described from the implementation.

14. Configure a dedicated management button

You can place a dedicated button at a suitable location on a process page. This is optional: without such a project button, the application provides the Users / Roles header button for authorized users.

1. Switch to the editor with an authorized account.
2. Insert a Basic objects → Button and open its properties.
3. Give it a distinct name and enter a caption such as “Users / Roles” in Text / initial value.
4. Open Buttonfunktion einstellen (configure button function) and select Benutzer / Rollen öffnen (open users / roles).
5. Apply the function dialog and object properties. This function requires no PLC address.
6. Save the project and test the button as an authorized user.

The caption alone is insufficient: the selected button function opens management. The button does not grant permissions. It is operable only when the signed-in account can manage users or roles; individual management actions still check their respective permissions.

Once any page in the project contains a button with this function, the additional header button is omitted. Place your entry on a page reachable by the responsible users. The login/logout user object and the management button serve different purposes.

These configuration steps are described from the implementation. The image above shows the runtime entry, not the dedicated button settings dialog. See inserting a button for the basics.