[Feature Request]: Ability to disable profile edit, password change, and asset tabs

[designatedsuccessor]

Is your feature request related to a problem? Please describe.

We use SCIM and SAML and have limited asset types, so we have no use for profile editing, password changes, and various tabs in users' profile pages. In fact, they only confuse users.

Describe the solution you'd like

We would like the ability to disable the following features:

• Profile picture, so no profile image would display at all for any users under any circumstances; we simply have no use for profile pics in our asset manager
• Ability to see (or at least edit) the content of this page: /account/profile
• Ability to see (or at least edit) the content of this page: /account/password
• The "Edit Your Profile" button here: /account/view-assets#details
• The "Change Password" button here: /account/view-assets#details
• The "Edit Your Profile" button when clicking on the username in the upper-right corner
• The "Change Password" button when clicking on the username in the upper-right corner
• The "hamburger" button in the upper-left corner; for our users, there is never anything in the left slide-out menu, so the hamburger button in the upper-left corner exists for no reason for our users; an alternative could be that the hamburger button and slide-out menu intelligently disappear anytime it detects there is nothing listed in it, so a disablement control wouldn't be necessary
• Display of the "Licenses," "Accessories," and "Consumables" tabs on this page: https://martincc.snipe-it.io/account/view-assets ; we assign only traditional assets to users so these tabs will forever be empty for all users; an alternative could be that these tabs disappear (or are at least greyed-out) if the user is assigned 0 items of that type, so a disablement control wouldn't be necessary

Where possible or feasible, we would prefer not displaying links/buttons/tabs rather than greying them out.

Describe alternatives you've considered

No response

Additional context

No response

[designatedsuccessor]

In the meantime, we have written the following CSS as a workaround. It seems to be working for our users in any case:

#details > div.row > div.col-md-3.col-xs-12.col-sm-push-9 > div, ul.dropdown-menu li:nth-child(3), ul.dropdown-menu li:nth-child(4), #webui > .row > div.col-md-12 > div.nav-tabs-custom > ul.nav.nav-tabs.hidden-print  li:nth-child(3), #webui > .row > div.col-md-12 > div.nav-tabs-custom > ul.nav.nav-tabs.hidden-print  li:nth-child(4), #webui > .row > div.col-md-12 > div.nav-tabs-custom > ul.nav.nav-tabs.hidden-print  li:nth-child(5), .navbar-nav > .user-menu .user-image {
   display : none;
}

However, this CSS does not hide the left aside pane (i.e., the one with the hamburger menu in the upper-left corner) because I cannot find a way to target it only for regular users. In other words, anything I could do would target administrators, too, which is undesirable.

[snipe]

These are kinda two different issues, one of which has already been discussed here (tho for the life of me I don't remember what the issue was named so I can't link it.) The ability to "hide" aspects of the system that are not used has been requested before, and will likely be something we implement in v7.

Since we're basically at a feature-lock for the v6.x line, adding the ability to hide a user's profile wouldn't come until v7 as well.

[snipe]

Where possible or feasible, we would prefer not displaying links/buttons/tabs rather than greying them out.

This makes for an inconsistent UI in our experience. "Why is that button missing??" - a disabled button allows us to provide a hover message that explains why that option is unavailable.

As an additional note for those playing the home game and have a slightly different use-case, hiding first-class items (Consumables, etc) from the non-superadmin UI has some unexpected knock-on effects that would need to be factored in - for example, if a user has permission to create, edit and delete other users but cannot see Consumables at all as an option (not even the count of those assigned to a user, since hiding it from the UI, they won't be able to see why they can't delete a user.

[designatedsuccessor]

I guess I have the opposite experience: I think users are more likely to be confused by a greyed-out button than the non-existence of a button. How could they be confused about something they didn't know existed?

If you're talking about Snipe-IT admins: maybe. But I personally prioritize the user experience of end users over administrator users.

[snipe]

If you're talking about Snipe-IT admins: maybe. But I personally prioritize the user experience of end users over administrator users.

The admins and their end-users are both our users, so this argument kinda doesn't hold up here. Overall, admins interact with the system far more than their end users, so it's our job to look out for them (both of them, of course, but weighted for most common use case).

Most end-end-users of Snipe-IT don't even know they're in Snipe-IT, so optimizing for 2% of the user base versus making something consistent (with a hover message that explains why) for the the 98% makes more sense.

If a user is not allowed to do a thing, we hide that UI element from them. If they have the permission but cannot, say, delete a thing because there are relationships and therefore actions that need to be taken before they can be deleted, we display the icon or button in a disabled status to indicate that the user you are logged in as has permission do the general thing, but you cannot do it on this particular thing at this time.

[designatedsuccessor]

Yeah, I totally don't agree with pretty much any of that and my experience has been completely different, but to each their own, so do what you want. :)

[snipe]

This has been added in 7.0.5. https://github.com/snipe/snipe-it/releases/tag/v7.0.5

GitHub

Release v7.0.5 · snipe/snipe-it

CautionSnipe-IT now requires PHP 8.1.2 or greater

This release largely handles some translation issues (especially related to backup notification emails), a few small importer issues related to da...

[snipe]

(Well, not the asset tabs stuff, but the ability to disable profile editing)

[designatedsuccessor]

@snipe was the ability to change password part of this? It looks like at least the button is there. Not sure if it actually works or not.