Contributors mailing list archives

contributors@odoo-community.org

Avatar

Re: booking of resources

by
Moduon Team, S. L., Jairo Llopis
- 19/01/2023 09:44:57
Hi Hughes!

El mar, 17 de ene de 2023 a las 19:56:59 PM, hugues de keyzer <notifications@odoo-community.org> escribiĆ³:
if there are 4 rooms, 3 video projectors and 5 people that can be combined freely, 96 combinations (including the ā€œno video projectorā€ and ā€œno waiterā€ choice) must be created (and each of them must be added to at least one resource.booking.type to be selectable). moreover, the client would need to search through all of these to find the desired one. and what if there could be multiple waiters? this feels awkward

Although you might feel like the combinations design is weird, the use case you're proposing here is actually a good reason why it exists.

Are customers able to do a single booking of 2 projectors? That's unlikely. Or 1 projector and 2 rooms? Also very unlikely. 1 projector, 1 room and 2 waiters? That could be. 1 projector and no waiters or rooms? Depends on the case. Are all projectors available in all rooms? Or some rooms have a projector installed statically that can't be booked for another room? Are all rooms in the same building, or are they in different buildings? Are all buildings in the same country? Are there big rooms that cannot be handled by just 1 waiter?

The amount of possible combinations (and more important: the impossible combinations) justifies the existence of resource.booking.combination.

So IMHO the best approach would be to simplify the usage of resource.booking.combination, instead of replacing it. Some ideas:

  1. Add a button "Generate combinations". The button opens a wizard that will help you create combinations massively.
  2. When the user is selecting the combination, improve the UX making them available to pick resources individually. The engine would then select the appropriate combination under the hood.
  3. Add an option to the type: "Allow all possible combinations". Then, when customer selects the combination, resource by resource (idea 2), if it doesn't exist, it will be created on demand.
Other than that, it seems to me like the use case you described fits perfectly in the resource_booking collection, so you'll probably be better improving them than reinventing them.

Reference