[UI] Dont show project view menu when user doesn't have permission

[BryanMLima]

Description

This PR improves clarity to the user concerning the project list view component. The current behavior disables the project view menu when an Account does not have permission to list projects. However, that can be a bit confusing for users, if they have no permission to list projects, then, the expected behavior would be to hide the component that the user does not have access to (that is what happens with other components). Therefore, this PR aims to hide the project view when the user does not have the permission list projects.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

Before:

After:

How Has This Been Tested?

This was tested in a local lab.

Login with an Account that had the permission to the api listProjects:
It displayed the Project Menu view as expected.

Login with an Account that didn't have the permission to the api listProjects:
The Project View Menu is not shown, as the After image in the Screenshots section.

[GabrielBrascher]

LGTM

[nvazquez]

@blueorangutan ui

[blueorangutan]

@nvazquez a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

[blueorangutan]

UI build: ✔️
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/6081 (SL-JID-1235)

[yadvr]

I suppose this is classical debate whether to show/hide an action/element or show them as disabled to the end user.

Disabling a widget/component signals explicitly the information that there exists a feature/widget/component that for some reason the user isn't allowed to access (but by doing that we make the user aware that the feature exists). Hiding the feature/component is another approach where we don't want the user to even know about the feature, that it even exists.

Projects is generally a fundamental/default feature to CloudStack, I suppose if you have a role that disables that, then you're probably disabling not just the listProjects API but perhaps the entire projects feature. In that case, hiding the drop-down entirely makes sense. Let us know @BryanMLima your thought process around this, what led to this?

[BryanMLima]

When comparing a feature like live scaling a VM, it makes sense to disabled the button when the user has the permission to do so, but the API cannot be executed considering some external factors, like the VM is not dynamically scalable, for example. In this case, showing the user that he can live scale a VM makes sense, even though he can't in that specific case.

However, when considering the API listProjects, the side menu does not show the Project section, so it makes sense to hide the Project Menu on the top bar as well.

Moreover, if the user has the permission to an API, then it should show at all times, even though the API can't be executed at that time, like the live scale mentioned above. In this case, it should be displayed as disabled. However, if the user doesn't have the permission to the API, it should not be displayed at all.

[nvazquez]

Thanks for the explanation @BryanMLima LGTM