[Feature] - Regrouping Hardware requested menu & requestable menu

[veenone]

Description

To improve the correlation on request management perspective, the requestable & asset requested menu is grouped together pertaining the original access condition for both.

By grouping them in a group called Request Manager, the activity of requesting & handling request will be in the same place and IMO will be less confusing

Fixes #11334

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Test A : test the new layout & the functionalities
• Test B : test the layout with different user role

Test Configuration:

• PHP version: 7.4.27
• MySQL version
• Webserver version
• OS version: Windows 10

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Screenshots

Before

After

[snipe]

I'm not sure I agree with this nav change - requestable and incoming requests are not really related in workflow. Regular users requesting items is one thing, while the incoming requests tends to be an admin only task. Most admins don't request assets for themselves, they would just check them out to themselves.

I'm open to being convinced, I'm just not sure this is the right approach. It puts the incoming requests further from the admin's asset workflow.

[veenone]

HI Snipe, thanks for your explanation. the fact that in for the past 3 years me and my team always do the workflow that you mentioned - they directly receive request by mail / chat and they do the checkout from the asset list directly, not knowing that there's a dedicated requested list to manage incoming requests. partially this due to the limitation on going through the documentation & language understanding barrier (my bad).

CMIIW, requested is more regularly used as operational activities compared to the rest which I think more into maintenance activities which less regularly change (again, maybe I'm wrong) so having it to be grouped with the other operational related activities would be better. by having this way I can direct specific team members to be in charge on these requestable & requested process and not to care on the other asset related menus. just these 2.

But on the other hand based on your explanation I might need to understand better on the current workflows and how to differentiate them in order to rearrange my current setup. Currently I just set 2 roles, admins who can do many things (many people) and users who can only read (people outside my team)

so far I understand what you're explaining and will check again about the ideal workflow with the tool. anyway any explanation in graphics regarding this one?