This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. CKG Edit <- .:role_change | ^ .:start | Documentation ^ .:role_attributes| -> ====== Agenda of universal requests ====== {{tag>universal request}} ===== What is a universal request? ===== The universal request agenda allows you to create a request for any (supported) object in the IdM. A advantage versus the previous agendas for dealing with requests is versatility when there is no need to create a separate agenda for each additional approved object (such as the agenda for automatic roles requests and the agenda of requests for change a permissions). {{ :devel:documentation:roles:dev:requests.webm?1000x700 |}} ===== How it works? ===== If the approval mode is enabled, it is not possible to edit the object on a standard URL. This means that even if the user has the right to edit, the object will be **read-only** (details will be read only, edit buttons will not be available, bulk operations will not be available). **An object can only be edited after you have moved to a specific request URL**. <note>**One of the main objectives of universal applications was to achieve the reuse of the UI components**. This means that if a user creates a request (which goes to a completely different URL), he should not visually see "no" change. He should feel that by simply creating a request, the form just switched to editing mode.</note> Example of a URL role and the same role edit role within the request: * **/role/**{role ID}**/detail** * **/requests/**{request ID}**/role/**{role ID}**/detail** {{ :devel:documentation:roles:dev:role_readonly.png |}} ==== Creation of the request's items ==== If we already have a request, we can start making individual **changes**. As described above, individual **REST** request calls are "redirected" to the REST request interface of that object type. Each partial change (called REST interface) creates a request item (**IdmRequestItem**). This item includes, in particular, ownership of the owner, that is, the link to the object being edited. Additionally, the request entry contains a **complete object** in the form of how to get from the interface. This object is used to apply changes when applying for approval. The object is saved in **JSON** format. This format has been chosen with respect to backward compatibility. There is a lower probability of any problems with a change in the structure of the target object. **JSON** format allows us to perform additional transformations (to ensure compatibility) against binary serialization of the whole object. <note>The **REST** interface is represented by the controller, for example, the role is the **standard** controller **IdmRoleController** and the **request** controller is **IdmRequestRoleController**.</note> {{ :devel:documentation:roles:dev:screenshot-localhost-3000-2018.10.10-14-05-13.png | }} ===== How to enable the requesting for specific object? ===== <note important>Requesting mode is controlled for all requestable objects by **IdmRoleDto** (for now)!</note> Requesting mode can be enabled for every supported object by property in the application configuration: <code> idm.pub.core.request.<requestable object>.enabled=true </code> , where **<requestable object>** is the name of requestable object (DTO). <note tip>For example **approving for role** (IdmRoleDto) can be enable by this property: <code> idm.pub.core.request.idm-role.enabled=true </code></note> ====== Read more ====== ===== Admin guide ===== * [[.requests:adm:universal_agenda|Agenda of universal requests]] * [[.requests:adm:approval-process|Requests and approval process]] * [[.requests:adm:|Requests without approval]] ===== Devel guide ===== * [[.roles:dev:universal_requests|]] ===== Limitations ===== <note warning>Enabling of the request mode is controlled only by **IdmRole** now.</note> <note warning>Changes in the request preview are highlighted only in tables. Types of changes are not shown in the object **details** or on **EAVs**!</note> by kotisovam Log In