Description of problem:
Request enhancement to WebUI to allow modifying the Password Expiration field.
Provide WebUI action for the below commands: ipa user-mod <username> --password-expiration=<date> <-- set ipa user-mod <username> --password-expiration= <-- unset
How reproducible:
Always
Steps to Reproduce:
Login to WebUI
On the "User" tab, click on a user
Account Settings -> Password Expiration
Actual results:
Password Expiration is a displaying-only property.
Expected results:
Password Expiration is an input text field allowing the admin to update.
The action buttons contained on that page for each field. Not including the 'Refresh', 'Revert', 'Save', and the ones in the kebab selector (those will be implemented in a separate task/PR).
The information string located in 'Identity' > 'Services' > 'Settings' > 'Service settings' should contain details for the 'External Identity Provider' checkbox option. This information is still not available upstream (see service.py).
Adapt the 'Active users' > 'Settings' to use the communication layer wrapper.
Acceptance criteria:
The wrapper should be used to create and perform the API calls needed in each case.
Implement action button functionality for all of the sections of 'Settings'.
The specific user data should be retrieved and shown in the different UI elements. The reading and writing access should be managed by the already retrieved environmental data.
The action buttons contained on that page for each field. Not including the 'Refresh', 'Revert', 'Save', and the ones in the kebab selector (those will be implemented in a separate task/PR).
The action buttons contained on that page for each field. Not including the 'Refresh', 'Revert', 'Save', and the ones in the kebab selector (those will be implemented in a separate task/PR).
The Users > 'Preserved users' > 'Settings' section
The action buttons contained on that page for each field. Not including the 'Refresh', 'Revert', 'Save', and the ones in the kebab selector (those will be implemented in a separate task/PR).
A small refactoring can follow this PR to generalize the CreateKeytabUsersTable, ... and the RetrieveKeytabUsersTable, ... components to have object or principal instead of host.
Adapt the 'Preserved users' > 'Settings' to use the communication layer wrapper.
Acceptance criteria:
The wrapper should be used to create and perform the API calls needed in each case.
Implement action button functionality for all of the sections of 'Settings'.
The specific user data should be retrieved and shown in the different UI elements. The reading and writing access should be managed by the already retrieved environmental data.
The action buttons contained on that page for each field. Not including the 'Refresh', 'Revert', 'Save', and the ones in the kebab selector (those will be implemented in a separate task/PR).
Currently, CI and dev environment depend on a manually added entry to Apache settings to serve the assets.
Our goal is to deliver freeipa-webui as a RPM package that can be installed alongside freeipa-server (and others).
The freeipa-server-webui package can be installed:
Before running ipa-server-install; or,
On an already deployed server.
With that in mind two scenarios are possible:
(Requires integration with freeipa) Running ipa-server-install with freeipa-webui present auto-configures Apache.
System administror runs ipa-webui-install to configure Apache (in an server with FreeIPA pre-installed)
In any case, after installing and configuring Apachae a server running FreeIPA will also respond to HTTP requests pointing to https://[IPA_SERVER]/ipa/modern_ui.
Considering that some accessibility aspects are already covered by the PatternFly4 library, this issue is meant to review other accessibility aspects that might be not covered by the library itself and/or depend on the application context (e.g., OUIA, inconsistent keyboard navigation, readability, etc).
Implement a wrapper using the RTK Query library for consuming the IPA commands via JSON-RPC in the new WebUI.
Acceptance Criteria:
Implement the solution using the RTK Query library and refer to its documentation.
Define the endpoints in the wrapper for making the API calls.
Each endpoint should refer to a different type of API call determined by the number of commands called (simple | batch) and the type of endpoint (Query | Mutation).
The API calls should cover specific IPA commands, but those do not need to be explicitly specified in the endpoint itself (only when they will be consumed).
If needed, use endpoints for defining sequential API calls (that need to be executed in a specific order, see example here) or other endpoints that complete further functionality not covered by the already defined endpoints.
Adapt the 'Stage users' > 'Settings' to use the communication layer wrapper.
Acceptance criteria:
The wrapper should be used to create and perform the API calls needed in each case.
Implement action button functionality for all of the sections of 'Settings'.
The specific user data should be retrieved and shown in the different UI elements. The reading and writing access should be managed by the already retrieved environmental data.
Description of the request:
It would be helpful to be able to control columns listed for resources in the WebUI and control the number of records displayed on a single page. It would also be helpful to be able to export this data to a CSV from the WebUI.
Reason behind this RFE:
Use Case:
To be able to see lists of active users and what they have access to. If they need a list of all of our users they have to page through them in the UI. We do know that CLI tools or LDAP browsing clients are an option, but these are generally non-technical users.
Allow auditors to view and export relevant data.
Functional requirements here:
Provide a mechanism to choose which columns are displayed. Provide an export to CSV functionality.
How Red Hat and the customer can test to confirm the requirement is successfully implemented?:
Description of the request:
To set which users and groups can modify an OTP token from the IPA web UI. This is related to BZ#1990576
Business requirements:
Not have to assign management users and groups through the command line, they would prefer to handle that from the web UI due to the fact they run MacOS in their company and additionally would prefer to not have to give access to the IPA command line as much as possible.
Functional requirements:
From the IPA web UI, they would like to have an option when creating the token to specify which users and/or groups are assigned as the token manager, and additionally would like to use the existing token manager tab (https://idm.example.com/ipa/ui/#/e/otptoken/managedby_user/) to be able to add and remove token managers.
How to confirm the requirement is successfully implemented?:
It can be tested in an example environment by being able to assign a test user and a test group as managers for a token assigned to another user.