Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: booking of resources
by
Moduon Team, S. L., Jairo Llopis
Hi Hughes!
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 awkwardAlthough 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:
- Add a button "Generate combinations". The button opens a wizard that will help you create combinations massively.
- 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.
- 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.
