The project needs the following content:

• The 'Hosts' > 'Is managed by' section
• The action buttons functionality contained on that page.

The project needs the following content:

• The Users > 'Preserved users' > 'Is a member of' section
• The different tabs and action buttons contained on that page.

This project interacts with FreeIPA via its RPC API. Thus, an RPC client is needed.

Explore the idea of running/serving the Web UI on a different host.

References:

• FreeIPA behind HTTP proxy with different hostname
• Auri - Self-service account creation and credential reset for FreeIPA

The project needs the following content:

• The Users > 'Active users' main page
• The action buttons contained on that page ('Add', 'Delete', 'Enable', and 'Disable').
• The modals on that page.

Goal:

• Change and adapt the user's components to the new user data type.

Acceptance criteria:

• The user components should use the newly-created data type and keep its functionality.

The project needs the following content:

• The 'Services' > 'Is a member of' section
• The different tabs and action buttons contained on that page.

Goal:

• Adapt the action buttons in order to match with the ones in the current WebUI.

Acceptance Criteria:

• 'Stage users' main page should have the following action buttons: 'Refresh', 'Delete', 'Add', and 'Activate'.
• As this is UI-based, there is no need to implement the functionality yet (this will be implemented in other PR)

Goal:

• Adapt the 'Preserved users' main page to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The list of users should be retrieved and shown in the main table.
• The bulk selector and pagination components should keep its functionality.

The project needs the following content:

• The Users > 'Active users' > 'Is a member of' section
• The different tabs and action buttons contained on that page.

The project needs the following content:

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

The project needs the following functionality:

• 'Settings' action buttons: 'Refresh', 'Revert', 'Save', and the ones contained in the kebab selector.
• Ideally, field validation. If this only task is more complex than expected, then this can be implemented in another task / PR.

The PaginationPrep component should be unique to manage the pagination data for all entity types.

Before:

• For 'users' --> PaginationUsersPrep
• For 'hosts' --> PaginationHostsPrep
• For 'services' --> PaginationServicesPrep

Goal:

• For 'users', 'hosts', 'services', and more --> PaginationPrep

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

Goal:

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

Goal:

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

Goal:

• Adapt the 'Active users' action buttons to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The action buttons functionality should be implemented to be used with the wrapper: 'refresh', 'delete', 'add', 'disable', and 'enable'.

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.

Goal:

• Adapt the 'Active users' main page to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The list of users should be retrieved and shown in the main table.
• The bulk selector and pagination components should keep their functionality.
• The calls to get the initial environmental data can be made if needed.

The project needs the following content:

• The 'Hosts' > 'Is a member of' section
• The different tabs and action buttons contained on that page.

Goal:

• Adapt the 'Stage users' action buttons to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The action buttons functionality should be implemented to be used with the wrapper: 'refresh', 'delete', 'add', and 'activate'.
• The functionality of any UI components can be enhanced if needed.

Add semantic-release to repo and integrate it with GitHub actions.

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

Use gherkin syntax to define the user story.

The project needs proper routing and a navigation bar to move across all the pages.

This will be implemented using the React router DOM library (v.6).

• Description of problem:
  List the ACME role in WebUI and its status.
  It would be good if the $ipa server-role command display the acme role too.

• How reproducible:
  NA

• Expected results:
  ACME role displayed in WebUI.

The project needs the following content:

• The 'Services' > '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).

The project needs the following content:

• The 'Hosts' > '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).

The project needs the following content:

• The Users > 'Stage users' main page
• The action buttons contained on that page ('Add', 'Delete', 'Enable', and 'Disable').
• The modals on that page.

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

The project needs the following functionality:

• 'Settings' action buttons: 'Refresh', 'Revert', 'Save', and the ones contained in the kebab selector.
• Ideally, field validation. If this only task is more complex than expected, then this can be implemented in another task / PR.

The project needs the following content:

• The 'Hosts' main page with some action button functionality.
• The 'Settings' section. With consideration of splitting this specific part into another issue if necessary.

Goal:

• Adapt the 'Preserved users' action buttons to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The action buttons functionality should be implemented to be used with the wrapper: 'refresh', 'delete', 'restore', and 'stage'.
• The functionality of any UI components can be enhanced if needed.

Goal:

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

• Description of the request:
  The customer wants a filter in the IPA GUI to hide revoked certs.

• Reason behind this RFE:
  To clean up the list of certs in the GUI.

• List the functional requirements here:
  There would need to be a filter/view added in the GUI.

Goal:

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

  1. Login to WebUI
  2. On the "User" tab, click on a user
  3. 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.

As the Kerberos Principal Alias' logic is been used in several pages (e.g., Services, Hosts, Users), this can be contained in a new component.

The component can possibly have also a parent, more general component - MultivaluedTextInput. That might be usable in other places as well.

The project needs the following content:

• The 'Services' main page with some action button functionality.
• The 'Settings' section. With consideration of splitting this specific part into another issue if necessary.

Goal:

• Adapt the 'Stage users' main page to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• The list of users should be retrieved and shown in the main table.
• The bulk selector and pagination components should keep its functionality.
• The calls to get the initial environmental data can be made if needed.

Goal:

• Adapt the 'Active users' > 'Is a member of' to use the communication layer wrapper.

Acceptance criteria:

• The wrapper should be used to create and perform the API calls needed in each case.
• Each group data list should be shown in its corresponding table.
• The functionality of the action buttons should be implemented.
• The functionality of any UI components can be enhanced if needed.

A small refactoring can follow this PR to generalize the CreateKeytabUsersTable, ... and the RetrieveKeytabUsersTable, ... components to have object or principal instead of host.

Originally posted by @pvoborni in #56 (comment)

The project needs the following content:

• The 'Service' > 'Is managed by' section
• The action buttons functionality contained on that page.

The Search input element needs to filter data from the following tables:

• 'Active users' page
• 'Is a member of' section tables
• 'Stage users' page
• 'Preserved users' page

• 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?:

  • Confirm you can choose the columns displayed.
  • Confirm export is successful.

The project needs the following content:

• The Users > 'Active 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).

• Implement jest framework into the project
• Implement unit tests for existing CL
• Enable GitHub action for running the unit tests

The project needs the following content:

• The Users > 'Preserved users' main page
• The action buttons contained on that page ('Add', 'Delete', 'Enable', and 'Disable').
• The modals on that page.

Goal:

• Adapt the action buttons in order to match with the ones in the current WebUI.

Acceptance Criteria:

• 'Preserved users' main page should have the following action buttons: 'Refresh', 'Delete', 'Restore', and 'Stage'.
• As this is UI-based, there is no need to implement the functionality yet (this will be implemented in other PR).

The project needs the following content:

• The Users > 'Stage 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).