[Feature request]: Implement "Self Service Plus" User Type with Enhanced Booking Capabilities

[carlosvirreira]

Contact Details

No response

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

Our current Self Service user type has limitations that can create bottlenecks in the booking process. Self Service users can only reserve their own bookings, but they rely on administrators to check out and check in the assets. This dependency on administrators can slow down operations and reduce efficiency, especially in organizations with high booking volumes or time-sensitive equipment needs.

Describe the solution you'd like

We need to implement a new user type called "Self Service Plus." This user type should have all the existing permissions of the Self Service user, with the added ability to check out and check in their own bookings independently. Specifically:

• Self Service Plus users should be able to create and reserve bookings (like current Self Service users).
• They should have the ability to check out their reservations.
• They should be able to check in assets at the end of their reservation period.
• All other permissions should remain the same as the current Self Service user type.

This enhancement will empower trusted team members to manage their bookings more efficiently, reducing the workload on administrators and streamlining the overall booking process.

Describe alternatives you've considered

1. Expanding the Self Service role to include check-out/check-in capabilities for all users. However, this might grant too much responsibility to all Self Service users.
2. Creating a new role between Self Service and Administrator. While this could work, it might add unnecessary complexity to our role system.
3. Implementing a request system where Self Service users can ask for check-out/check-in approval from admins. This could add an extra step and potentially slow down the process.

Additional context

This feature is crucial for organizations that want to maintain control over who can create bookings while still allowing trusted individuals to manage the entire booking lifecycle. It will be particularly beneficial for teams with remote workers, multiple shifts, or those operating outside of standard business hours when administrators might not be available.

[DonKoko]

We just need to address the points we discussed on discord:

• The name Self Service is better fitting to this new type, so lets come up with a name to replace all current Self service users
• Add a place where users can ask/change user type
• Prepare a good update for our users to be informed about this

[carlosvirreira]

After careful consideration, we've decided to rename the current "Self Service" user type to "BASE". This name reflects its foundational role in our user hierarchy while clearly differentiating it from the new "Self Service" type.

The BASE user will have the following permissions:

• View assets
• Create booking requests for themselves
• Cannot check out or check in assets
• Limited access to settings (only own account details)

For clarity, here's a comprehensive table of our user types and their capabilities:

User Type	Capabilities
Account Owner	• Full access to all features • Manage subscriptions and billing • Create and manage all user types • Perform all actions on assets, bookings, and settings
Administrator	• Full access to workspace features • Manage assets, categories, tags, and locations • Create, update, and fulfill bookings • Manage users within the workspace • Configure workspace settings
BASE (formerly "Self Service")	• View assets • Create booking requests for themselves • Cannot check out or check in assets • Limited access to settings (only own account details)
Self Service	• All capabilities of BASE • Can check out and check in their own bookings • Still limited access to settings

This structure provides a clear hierarchy of user permissions, from the foundational BASE user to the fully-empowered Account Owner. The new Self Service type bridges the gap between BASE and Administrator, offering more autonomy in the booking process without full system access.

We believe this naming convention and permission structure will improve clarity for our users and streamline the asset management process. Your thoughts and feedback on this decision are welcome.

[carlosvirreira]

@DonKoko addressing the last two bullet points above.-

Add a place where users can ask/change user type:

• Utilize the existing three-dot action dropdown for each user in the Team tab
• Add a new option "Change User Type" to this dropdown (visible only to Administrator and Owner roles)
• When "Change User Type" is selected, open a modal with options to switch between BASE and Self Service
• For non-admin users, replace "Change User Type" with "Request User Type Change" in their own dropdown
• "Request User Type Change" opens a modal where users can select desired type and provide a reason > These get sent per mail to the admin/owner

Prepare a good update for our users to be informed about this:

Dear Shelf Users,

We're excited to announce important updates to our user roles system, designed to give you more flexibility in managing assets. Please read carefully as these changes affect how you interact with Shelf.

What's Changing:

1. Role Renaming and New Role:

   • The current 'Self Service' role is now called 'BASE'.
   • We've introduced a new 'Self Service' role with enhanced booking capabilities.

2. New Role Capabilities:

   • BASE Role (formerly Self Service): • Can view all assets • Can create booking requests • Cannot check out or check in assets

   • New Self Service Role: • Has all BASE role capabilities • Can also check out their own bookings • Can check in assets at the end of their booking period

3. How to Request a Role Change:

   • Go to the Team tab in Workspace settings
   • Find your name and click the "..." menu next to it
   • Select "Request User Type Change"
   • In the modal that opens, select your desired role (BASE or Self Service)
   • Provide a reason for your request
   • Submit your request – it will be sent via email to your workspace administrator or owner

4. For Administrators and Owners:

   • You can now directly change user roles from the Team tab
   • Use the "..." menu next to each user's name
   • Select "Change User Type" to update instantly

Why We're Making These Changes:

These updates will streamline the booking process and provide more autonomy to trusted team members, reducing administrative bottlenecks.

What You Need to Do:

• Review your current role in the Team tab
• If you need enhanced booking capabilities, submit a request for the new Self Service role
• If you're satisfied with your current access, no action is required

We're here to support you through this transition. If you have any questions, please don't hesitate to reach out to our support team.

Thank you for your continued trust in Shelf. We're committed to improving your experience with every update.

Best regards, Carlos Virreira Founder, Shelf Asset Management, Inc.

[DonKoko]

Implementation plan:

Base feature

• [x] Add a new OrganizationRole called BASE
• [x] Adjust the permissions map, so that current SELF_SERVICE permissions are actually for base users
• [x] Write a script to migrate all SELF_SERVICE users to BASE
• [x] Add new SELF_SERVICE permissions to permissions map
• [x] Update all UI elements where users can set roles to have friendly names for BASE user type
• [x] Adjust all isSelfService checks to isBaseRole and create different checks for isSelfService - - - or come up with an updated system for managing this
• [x] Update SSO groups mapping to roles
• [x] Update SSO documentation for groups mapping

Supporting UI

• [ ] Add a modal on the team page that allows the user to see what the permissions of each role are

[DonKoko]

@carlosvirreira @jurrejansen this is deployed to testapp and ready for testing. I already did some tests myself. Made some small fixes that are being deployed now: https://github.com/Shelf-nu/shelf.nu/actions/runs/10073681610 Some important stuff to check:

• That both user types have correct permissions related to bookings
• That admin can correctly see bookings created by both self service and base users

[carlosvirreira]

@carlosvirreira @jurrejansen this is deployed to testapp and ready for testing. I already did some tests myself. Made some small fixes that are being deployed now: https://github.com/Shelf-nu/shelf.nu/actions/runs/10073681610 Some important stuff to check:

• That both user types have correct permissions related to bookings
• That admin can correctly see bookings created by both self service and base users

Sounds good, will test after I finish my current task.

[carlosvirreira]

NOT BREAKING COMMENTS JUST CONSIDERATIONS WE CAN SHIP ANYWAYS

BASE User

1. Cancellation of Ongoing Bookings:

   • BASE users can cancel ongoing bookings. We should discuss if this is the intended behavior.

2. Visibility of Upcoming Bookings:

   • BASE users cannot see upcoming bookings. This might be a privacy feature, but we should form a clear opinion on this.

3. Asset Management in Ongoing Bookings:

   • If an admin removes all items from a booking, BASE users can 'manage' assets when the booking is ONGOING. This behavior needs review.

Admin Capabilities

1. Booking Manipulation:
   • Admins can remove all items from a booking, leaving it ongoing indefinitely.
   • These modified bookings don't appear in activity logs or booking lists. Consider if this is desired behavior.

SELF SERVICE User

1. Kit Reservations:

   • Users can reserve individual items from a kit, potentially causing conflicts. (Condition, the asset has to be reserved first and THEN added to a kit).
   • Cannot add assets to a booking if they're part of a kit, which is good.
   • At the kit level, users can remove available assets but can't add more.

2. Asset Management:

   • Mid-booking, admin can add assets via 'Manage Assets', potentially interfering with other bookings.
   • Assets added this way are tagged as "Already Booked" but can still be checked in and are effectively checked out.

General Observations

1. UI/UX:

   • Consider showing the contents of a kit if possible.

2. Conflict Management:

   • When adding an already booked asset, consider showing who currently has it booked to prevent unintended conflicts.

Suggestions for Improvement

1. Review the cancellation permissions for BASE users on ongoing bookings.
2. Clarify the policy on visibility of upcoming bookings for BASE users.
3. Implement stricter controls or warnings when actions might interfere with other users' bookings.
4. Consider adding significant booking modifications to the activity log.
5. Improve transparency when dealing with kit reservations and their individual components.
6. Enhance the UI to provide more context when actions might affect other bookings.

[DonKoko]

TODO

Making a checklist from the points above. Most of them are bugs and need to be addressed asap:

• [x] BASE users can cancel ongoing bookings. We should discuss if this is the intended behavior.
• [ ] BASE users cannot see upcoming bookings. This might be a privacy feature, but we should form a clear opinion on this.
• [x] If an admin removes all items from a booking, BASE users can 'manage' assets when the booking is ONGOING. This behavior needs review.
• [ ] Admins can remove all items from a booking, leaving it ongoing indefinitely.
• [ ] These modified bookings don't appear in activity logs or booking lists. Consider if this is desired behavior.
• [ ] Mid-booking, admin can add assets via 'Manage Assets', potentially interfering with other bookings. Assets added this way are tagged as "Already Booked" but can still be checked in and are effectively checked out.

---

Addressing some other points

Users can reserve individual items from a kit, potentially causing conflicts. (Condition, the asset has to be reserved first and THEN added to a kit).

This is not related to this PR and indeed it works like this. We decided to leave it up to the user when we developed this feature. I do agree we might have to add some controls there, but I would separate that from the roles scope

At the kit level, users can remove available assets but can't add more.

I don't understand in what context this is. I need some more info.

---

I will address all the points below when I finish with the issues above.

General Observations

UI/UX:
    Consider showing the contents of a kit if possible.

Conflict Management:
    When adding an already booked asset, consider showing who currently has it booked to prevent unintended conflicts.

Suggestions for Improvement

Review the cancellation permissions for BASE users on ongoing bookings.
Clarify the policy on visibility of upcoming bookings for BASE users.
Implement stricter controls or warnings when actions might interfere with other users' bookings.
Consider adding significant booking modifications to the activity log.
Improve transparency when dealing with kit reservations and their individual components.
Enhance the UI to provide more context when actions might affect other bookings.

[DonKoko]

Admins can remove all items from a booking, leaving it ongoing indefinitely.

Indeed they can remove all items. However even if they remove everything, check in is still possible. I think this is an example of an action that is possible but makes no real life sense, so I am not worried about it. If users complain we can change it.

These modified bookings don't appear in activity logs or booking lists. Consider if this is desired behavior.

I dont understand this. What are "these modified bookings" and which "activity logs" you mean.

Mid-booking, admin can add assets via 'Manage Assets', potentially interfering with other bookings. Assets added this way are tagged as "Already Booked" but can still be checked in and are effectively checked out.

This is one of the things that is about user agency. I personally think its fine like this. When a user performs an action like this that conflicts with real life physical limitations, I feel they should be responsible for it. We can of course change this and make it more control focused.

BASE users can cancel ongoing bookings. We should discuss if this is the intended behavior.

I don't think this should be possible. They could take some stuff and then just cancel the booking. I have fixed it. This is an issue caused by the refactoring of permissions.

If an admin removes all items from a booking, BASE users can 'manage' assets when the booking is ONGOING. This behavior needs review.

Thanks, I have fixed it. Indeed one of the buttons was enabled.