> For the complete documentation index, see [llms.txt](https://docs.videc.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.videc.de/june5-3.7/en/webanwendung/objektmodell-anlagenmodell.md). # Object Model (Plant Model) The Object Model view is the central contact point for managing permissions for all objects. In JUNE5, permission management is tied to the user hierarchy. Permissions on objects can therefore only be granted one level down the hierarchy. Thus the following applies: * The system administrator can only manage object permissions for tenants. * The tenant administrator can only manage object permissions for permission groups. Therefore, the system administrator *(1)* must first release objects for the tenant *(2)* so that the tenant administrator can manage object rights for permission groups *(2.2 and 2.1)*. ![](/files/uVwRvoP8ENOtAI9r4Lbg) {% hint style="info" %} System administrators, tenants, and users must be created in advance, see chapter [User Management](/june5-3.7/en/webanwendung/benutzerverwaltung.md). {% endhint %} ## Assigning Permissions for Objects In the menu on the right side of the screen, the *Object Model* area is accessed via the *Object Model* command. The possibilities for assigning permissions differ between the system administrator and the administrators of the respective tenants. In all cases, a selection must first be made from the dropdown menu in the top left (Permission Group). The table for managing permissions will then be visible. It consists of three columns: * *Name* presents the object name *(clickable!)* * *Permission* presents a dropdown list field with permissions * *Inherit* presents a checkbox for inheriting the current permission to child objects The table always starts with the root element of the object tree. Clicking on a specific name navigates to the next deeper level in the object tree. The navigation points traversed are listed in the breadcrumb navigation. Navigation back is possible via this. At each object level or hierarchy level, the desired permission can be set. By setting the Inherit checkbox, the currently set permission is inherited to child objects. The permission set by the parent object is always displayed in brackets next to the *Inherited (...)* label on child objects. The inherited permission can be subsequently overridden individually on child objects. To do this, change the permission on the desired child object using the dropdown menu. In this case, it is called an explicitly set permission. The example below represents how the set permissions affect child objects. The object numbered *(1)* represents the root element. For this object, the permission *Read/Write* was set. The *Inherit checkbox* was also set here. This enforces that the child objects 1.1 - 1.3 inherit the *Read/Write* permission. The object *(1.3)* subsequently received an explicitly set permission. Individually, the inherited *Read/Write* permission was changed to *Read*. Thus the inherited permission was overridden by the explicit permission. As a result, objects 1.1 and 1.2 have inherited *Read/Write* permission and object 1.3 has explicit *Read* permission. Also, the *Inherit checkbox* is set on object (1.3), which means that child objects 1.3.1 - 1.3.4 inherit the *Read* permission. Here too, it is again possible that some of the child objects should not inherit this permission and should instead also receive explicit permissions. In this case, this applies to object (1.3.3). ![](/files/pG0v7UcaNsqI8tkfe8XX) {% hint style="info" %} Before each reload of the table content, the changes must be saved. This is also reminded in the form of a message. {% endhint %} ## Permission Types The following permissions can be granted to objects in the object model: #### Inherited This is the default permission of an object. If the permission is set this way, the permission is inherited from higher levels in the object hierarchy. If no explicit permission is set from the object to the root object of the object hierarchy tree, no permission is inherited. The object is not visible. #### Read The corresponding object can only be read by the currently selected organizational unit. #### Write The corresponding object can only be modified by the currently selected organizational unit (e.g., via the Web API interface to enter a manual value). #### Release or Read/Write The corresponding object can be both read and modified by the currently selected organizational unit. #### Locked The corresponding object is locked for the currently selected organizational unit (not visible). ### Application Example ***Employee Hans:*** Functional rights to create or delete objects, which are configured in [User Management](/june5-3.7/en/webanwendung/benutzerverwaltung/funktionale-rechte.md). | | **Hans is a member of these groups** | **Hans's Effective Permission** | | | | | ---------------------- | ------------------------------------ | ------------------------------- | ------------ | ------------ | - | | **Permissions:** | **\[PRV]Hans** | **Master** | **Operator** | **Observer** | | | LineChartCreate | ☑ | ☐ | ☐ | ☐ | ☑ | | ManualValueTableCreate | ☐ | ☑ | ☐ | ☐ | ☑ | | SingleValueCreate | ☐ | ☐ | ☑ | ☐ | ☑ | | TrafficLightCreate | ☐ | ☐ | ☐ | ☐ | ☐ | Functional rights are ***OR'd***. ***Object Model Permissions:*** *Locked, Read/Write, Write, Read, Undefined*. | | **Hans is a member of these groups** | **Hans's Effective Permission** | | | | | --------------------- | ------------------------------------ | ------------------------------- | ------------ | ------------ | ------------ | | **Permissions:** | **\[PRV]Hans** | **Master** | **Operator** | **Observer** | | | **PVG** (J5001DE.PVG) | *Locked* | *Write* | *Undefined* | *Read* | *Locked* | | **PVG** (J5001DE.PVG) | *Read/Write* | *Locked* | *Read* | *Read* | *Locked* | | **PVG** (J5001DE.PVG) | *Write* | *Read/Write* | *Locked* | *Read* | *Locked* | | **PVG** (J5001DE.PVG) | *Read/Write* | *Write* | *Read* | *Undefined* | *Read/Write* | | **PVG** (J5001DE.PVG) | *Write* | *Read* | *Undefined* | *Undefined* | *Read/Write* | | **PVG** (J5001DE.PVG) | *Undefined* | *Undefined* | *Undefined* | *Read* | *Read* | | **PVG** (J5001DE.PVG) | *Write* | *Undefined* | *Undefined* | *Undefined* | *Write* | ***Ranking:*** | Locked | 5 | Highest | | ---------- | - | ------- | | Read/Write | 3 | | | Write | 3 | | | Read | 3 | | | Undefined | 1 | Lowest | The combination of *Read* and *Write* permissions in different groups results in the addition of both rights to *Read/Write*. ## Reading Models from Data Sources Instead of publishing the models of data sources *(such as the acron model)*, the JUNE5 plant model ensures decoupling between the model and the data. Thus, the models of the data sources are imported into the JUNE5 plant model and changes that occur at runtime are only synchronized with the plant model. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.videc.de/june5-3.7/en/webanwendung/objektmodell-anlagenmodell.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.