<- .: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>