Workflows¶
The Workflow module handles access to restricted applications. An application marked as restricted in its access contract is not launched directly by the user: the user must first send a request from the portal. The administrator accepts or refuses this request from this module, which produces a workflow attached to the user/application pair with optional time-based restrictions.
The module is organised in two tabs:
- Workflow — existing workflows (already granted accesses).
- Users' requests — requests waiting, accepted or refused.
Accepting a request automatically creates the matching workflow. Deleting a request also deletes the linked workflow.
Workflow tab¶
Workflows list¶
| Column | Description |
|---|---|
| Name | Workflow name. |
| Domain | Authentication domain of the user. |
| User | Account to which access is granted. |
| Applications | Application concerned. Beyond one, a + 1 other application or + n other applications counter is added. |
Each row can be expanded to show the restrictions (date range, time window, maximum session duration, one-time access, mandatory comment). When a workflow wraps several sub-workflows, the detailed list of sub-workflows is displayed, each with an individual delete button.
The toolbar offers:
| Action | Description |
|---|---|
| × (Delete) | Deletes the selected workflow after confirmation. Multi-selection is supported. |
| Search field | Filters by substring, under the Search placeholder. As long as there is no workflow, the grid shows No Workflow. |
| Pagination | 15, 25 or 50 rows per page. |
Delete a workflow¶
Select a workflow and click ×. When deleting a workflow triggers a user notification (see notification profiles), the confirmation window offers an optional Administrator comment field; that comment is included in the notification.
Deleting a workflow also deletes the associated user request.
Automatic deletion
Obsolete workflows (expired validity period, exhausted one-time access, maximum session duration reached) are deleted automatically by the system.
Users' requests tab¶
Requests list¶
The requests sent from the user portal appear here.
| Column | Description |
|---|---|
| Status | Icon whose tooltip gives the state: Waiting, Accepted or Refused. |
| User | Account that submitted the request. |
| Domain | Authentication domain of the account. |
| Applications | Requested application. Beyond one, the same counter as in the previous tab is added. |
| Submission date | Timestamp of the request, in DD/MM/YYYY - HH:MM format followed by the time zone. |
| Workflow | Name of the workflow created for this request, if any. |
A collapsible Filters block restricts the list by status (Waiting, Accepted, Refused) through check-boxes. A Filter button applies the selection.
A search field filters by substring.
Accept a request¶
Select a Waiting request, then click Accept the request. A workflow creation window opens, pre-filled with the user, the domain and the requested resource.
The form contains:
| Section | Description |
|---|---|
| Name | Name of the workflow. Mandatory. Maximum 256 characters. A name already in use triggers an error message. |
| Applications | Category tree of the resources covered by the request. At least one resource must be checked. |
| Domain / User | Read-only fields showing the values from the request. |
| Administrator comment | Free text; its content is forwarded in the notification sent to the user, when applicable. |
The available restrictions stack:
| Restriction | Description |
|---|---|
| Unique usage | The application can be launched only once. |
| Mandatory comment | Asks the user to enter a comment before launch. |
| Date | Date range (start / end). The end date must be ≥ start date. |
| Hour | Time window HH:MM. If a date range is active and start and end fall on the same day, the end time must be strictly after the start time. |
| Maximum session duration | Duration HH:MM after which the session is closed. Not available for a Generic tunnel application. |
If the access contract asks the user to fill a form, the Show user request button displays the submitted details. The window then contains a Pre-fill with this data button that copies the values into the acceptance form (after confirmation).
Creation without restrictions
Validating a form without ticking Unique usage, Date, Hour or Session duration produces a workflow without time limit. A dialog asks for an extra confirmation before creation.
Refuse a request¶
Only Waiting requests can be refused. Select the request and click Refuse the request. If action notifications are enabled and the request is concerned, an optional comment can be entered before confirmation.
A refusal does not prevent a new request
The user can request the same application again right away. On the new request, the refused request is purged automatically: the application is removed from it, and the request itself disappears if it carried only that one.
What does prevent a new request is a workflow already granted for that application, or a request still awaiting an answer — in both cases the application is simply dropped from the new request.
Delete a request¶
Only Accepted or Refused requests can be deleted. Select the request(s) and click the × (Delete) button. Multi-selection is supported when every selected request has already been answered.
- Deleting an accepted request revokes the authorisation and deletes the associated workflow.
- Deleting a refused request only removes the row from the list: the user could already submit a new request (see section Refuse a request).
If action notifications are enabled and at least one of the deletions will trigger a mail, an optional administrator comment is offered before confirmation.