Fixes #37228 - Replace Ansible/Roles page with React component

[Thorben-D]

Feature #37228

The new component acts as a drop-in replacement for the previously used erb-table.

This is required by #707

[sbernhard]

What is blocking us from using this change? Possibly at the start of a new release cycle?

[nofaralfasi]

What is blocking us from using this change? Possibly at the start of a new release cycle?

I'll review it ASAP.

[nofaralfasi]

The functionality works well. However, the page is loading much slower than before. I’m wondering if it’s an issue on my side or if the new code is causing the app to load slower.

[Thorben-D]

@nofaralfasi
Unfortunately, this is a side-effect of React rendering the component on the client-side. I am unsure when exactly react-rails renders components, but it feels pretty late (c.f. /new/hosts). Rendering server-side would help in this regard, but that does not work when window or document are used.

[sbernhard]

Of course, the site load would be pretty fast but rendering the page takes longer as its done in the browser itself.
Should it have a spinner as this was done in Katello/Content-views for example?

[ekohl]

In Foreman we have the TableIndexPage component which is intended for these index pages. Have you considered using that and if so, why was it insufficient?

[MariaAga]

+1 to Ewouds question, the js loading is slower between ruby and js, but faster between full React pages.
Can this be a full react page? it will need to be added in webpack/routes/routes.js, config/routes.rb

[Thorben-D]

Sorry for the delay, I was occupied otherwise.
Thank you for your feedback. I would actually prefer a full React page as-well! I chose this approach to keep the changes as low-profile as possible, but I am happy to move it to a full page.
Regarding TableIndexPage, I'm afraid, I couldn't get it to work... Do you have an example where this was used outside of foreman? (The page not the hooks!)

[MariaAga]

Webhooks use it here: https://github.com/theforeman/foreman_webhooks/blob/master/webpack/ForemanWebhooks/Routes/Webhooks/WebhooksIndexPage/WebhooksIndexPage.js

[Thorben-D]

Thanks, that's what I was looking for.
I checked out the component and the biggest issue I see with it is the way the action buttons are handled.
The old page allows the selection of a smart proxy to import roles from through a dropdown button.
While ActionButtons does provide a dropdown, it is toggled by a "kebab" toggle and not a component with text on it.

[Thorben-D]

^^Nevermind, I just noticed the customToolbarItems prop...

[Thorben-D]

Sorry for the holdup, I was occupied otherwise.
I re-wrote the whole thing to use the TableIndexPage component. I decided to adapt the ui_ansible_roles endpoint for this, as I did not find any usages.
Tests are still missing, but I will of course add some once we agreed on the UI.

[ekohl]

I don't see any permission filtering here. Am I missing something?

Also, couldn't this just use the regular REST API to delete roles?

[Thorben-D]

Indeed, I forgot to add the permission.

The table component uses the same endpoint for querying and deleting items, so it's unfortunately not possible to use the API just for deletion.

[nofaralfasi]

Are we sure this is the right approach? Adding an API call here doesn't seem right to me. I know it might be simpler, but we can still use the existing API call to delete a role. It might require some frontend adjustments, but it will align with the rest of our code.
For reference, this is how we do it on the new hosts page: https://github.com/theforeman/foreman/blame/6aac916fb183f47596e8d543756faac27750a21e/webpack/assets/javascripts/react_app/components/HostsIndex/index.js#L283

[Thorben-D]

Unfortunately, this would require significant changes to TableIndexPage.js and Table.js in core, as the idea is that TableIndexPage represents an interface to a single controller that has the necessary CRUD methods.
One could add another prop, deletionURL to TableIndexPage and Table that would take precedence over the original URL for deletion but I am not sure that is a cleaner solution.

[nofaralfasi]

Can't we add the Delete option to the rowKebabItems action items instead of using the isDeleteable property? From there, we can use the URL of the existing API for the delete action.

[Thorben-D]

Unfortunately, we would lose the delete modal that way.

[Thorben-D]

I added some tests for the React components.
I decided to omit a test for the AnsibleRolesPage component, as it is basically just a static wrapper for TableIndexPage, which is already extensively tested.

[nofaralfasi]

The page is significantly improved now. Thank you, @Thorben-D, for your hard work!

Here are a few notes from me:

• The "Import from" button is positioned on the same row as the top navigation, causing it to appear centered on the page.
• Table rows have a clickable cursor, but clicking them does not trigger any action.
• Clicking the Documentation button opens it in the current window.
• If the current user lacks permissions to view hosts or hostgroups, the corresponding options in the action menu should be disabled (same as we have now for the delete option).
• When the current user has permissions only to import roles (without viewing permissions), loading the Ansible Roles page results in the following error message: "There was an error requesting Smart Proxies," and the smart-proxy cannot be selected.

[MariaAga]

The "Import from" button is positioned on the same row as the top navigation, causing it to appear centered on the page.

This is fixed in foreman core

Table rows have a clickable cursor, but clicking them does not trigger any action.
Clicking the Documentation button opens it in the current window

Those are issues from foreman core

[Thorben-D]

Thanks for testing! I looked into the error you discovered.
It was caused by the user not having the view_smart_proxies permission. I added a check for that one as well and now the dropdown works correctly.
Apparently, the old UI also implicitly required this permission. It does make sense if you think about it, but I feel like permissions that depend on other permissions should be avoided... Not sure.

Regarding the "view X" buttons, while it is of course possible to hide those based on permissions, I would either have to lift the existing request up or add a second one to make it work. Both solutions would noticeably slow the page down however.
At that opportunity, I want to shamelessly refer you to this proposal, which would solve this issue cleanly.
Also, now If a user tries to view hostgroups for example, he is informed that he would need the view_hostgroups permission to do so. I feel like that could have some value. Not sure what would be best here either...

[sbernhard]

@nofaralfasi / @ekohl This PR is now open since Mar 6 and we invested a lot to improve foreman_ansible here. @Thorben-D answered all the questions and worked hard to get it done.
What is preventing us from merging this?

[nofaralfasi]

@Thorben-D Could you please rebase the PR? I'll re-check the permission issue, and let's see if the tests pass after the rebase.

Update:
Deleting Ansible Roles option isn't enabled on the Roles page, for a non-admin user with destroy_ansible_roles permission.

[Thorben-D]

Thank you for having another look!
Indeed, there was an issue with permissions again. Apparently, the authorized_for method I used before did not behave correctly. I replaced it with a different solution.
Test failure is also fixed.
Sorry about the linting, I am getting some psych error once again on my test-setup. It's nice though that linting issues are now shown in the diff!

[nofaralfasi]

Can we add a test to verify that a user without the destroy_ansible_roles permission cannot perform this action?

[Thorben-D]

I am not sure if this is necessary. The permissions should already be tested by a test in core and I didn't really find an existing test that tested this.

[sbernhard]

@MariaAga what are your thoughts about this?

[MariaAga]

Not my area, but I couldnt find a test in core for it in core

[nofaralfasi]

Overall, it looks good to me. Once Ewoud's and my comments are addressed, I believe we should merge this

[nofaralfasi]

I would expect to receive a proper error message when the user doesn't have the necessary permissions to view this page.

[Thorben-D]

@nofaralfasi The server actually sends back the following message:
"Missing one of the required permissions: view_ansible_roles"
Unfortunately though, the useAPI hook, currently, does not store this information in the store.
Given that a user does not normally get to this stage via the navigation, I think this is acceptable for now.

[nofaralfasi]

@Thorben-D what about permissions to view hosts or hostgroups? I think we should disable the buttons that are not permitted in the action menu.

Update: after discussing it with @ekohl, we agreed that to maintain consistency across the UI, this table should be aligned with the others. Specifically, the view actions for hosts and hostgroups should be presented as links within their respective column counts.

[Thorben-D]

Apologies, I did not see the last comment. I updated the design to match the desired outcome. Links in the columns will only be given if a user has the authorization to view them.