You are viewing the documentation for an outdated or unreleased 9.5 version.
This page is also available in versions: 9.3, 9.4, 9.5, 9.7 (current), devel

Agenda of universal requests

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

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.

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.

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

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.

The REST interface is represented by the controller, for example, the role is the standard controller IdmRoleController and the request controller is IdmRequestRoleController.

Requesting mode is controlled for all requestable objects by IdmRoleDto (for now)!

Requesting mode can be enabled for every supported object by property in the application configuration:

idm.pub.core.request.<requestable object>.enabled=true

, where <requestable object> is the name of requestable object (DTO).

For example approving for role (IdmRoleDto) can be enable by this property:
idm.pub.core.request.idm-role.enabled=true

Read more

Enabling of the request mode is controlled only by IdmRole now.
Changes in the request preview are highlighted only in tables. Types of changes are not shown in the object details or on EAVs!