[merci] MERCI (Manage Equipment Reservations, Checkout and Inventory) [#2625350]

# Summary

MERCI can extend any entity type into a list of unique reservable items (like studios) or buckets of interchangeable items (like DV cameras). At the most basic level MERCI defines validation constraints used when creating a reservation entity holding a start and end date and enityreference to a reservable resource. I.e. is the resource already reserved during the current dates. Currently the 8.x module provides the constraint for conflicting reservations and also defines fields and content types for reservable items and reservations.

# Project URL

https://www.drupal.org/project/merci

# Where is the code?

https://www.drupal.org/node/2621008

# Estimated completion date

Unknown.

# Dependencies

None.

# Who's doing the port?

darrick

# What help do they need?

Any feedback and testing. Most of the functionality can be provided in configuration. So, settling on a framework for the core is the biggest issue.

# D8 roadmap

# Background and reference information

#2151715: Status update on 7.x-3.x branch
#2621782: SQL::addWhere not defaulting to "IN" operator when using EntityReferenceView for multiple values
#2161337: Add a Date Range field type with support for end date

Comments

Comment #1

29 November 2015 at 20:27

darrick created an issue. See original summary.

Comment #2

darrick CreditAttribution: darrick commented 29 November 2015 at 20:30

Issue summary:

View changes

Comment #3

darrick CreditAttribution: darrick commented 29 November 2015 at 20:33

Issue summary:

View changes

Comment #4

wackywalter017 CreditAttribution: wackywalter017 commented 17 February 2016 at 17:27

Hello darrick,

My group is currently running a Drupal 6 site with MERCI, and we thoroughly appreciate all the amazing features MERCI has. Right now, we are in the process of upgrading our Drupal 6 website to Drupal 8. As part of that work, we are considering how best to keep our MERCI calendars functional. Options we are considering:

1) Migrate our MERCI content to a dedicated temporary Drupal 7 site, until we can switch to MERCI 8.

2) Keep running MERCI 6 as its own site, until we can switch to MERCI 8.

3) Some third option that hasn't occurred to us.

Which road would you recommend? If you anticipate MERCI 8 being ready very soon, with a smooth migration path, then option (2) seems appealing to avoid a double upgrade. Otherwise, migrating to MERCI 7 in the interim would move our system away from some MERCI-6-specific issues. What do you think?

Thank you very much for all your insight and hard work on this great module!

Comment #5

darrick CreditAttribution: darrick commented 17 February 2016 at 17:52

Probably best to upgrade through D7. Migrating 6 to 7 is fairly straight forward. It's been a long time since I last did it and the only issue I recall is the date field had to rolled back and then remigrated. I don't think I'll have the time to write the code for a 6 to 8 migration.

Comment #6

darrick CreditAttribution: darrick commented 17 February 2016 at 17:53

Issue summary:

View changes

Comment #7

rdworianyn CreditAttribution: rdworianyn commented 17 April 2017 at 16:02

I was looking through a bunch of the modules included with MERCI, like: merci_ui, merci_inventory, merci_calendar_view, merci_permissions, & merci_staff and saw that these are not ported to Drupal 8. We would be available to help migrate these if the work is not completed already. Please let me know the status/plans for all of these and what we can do to assist.

Comment #8

darrick CreditAttribution: darrick commented 18 April 2017 at 18:50

This has been the back burner a bit while waiting for the daterange module to get into core.

That said the core merci module is still very much in alpha mode. The current idea is to try to keep things simple and see what feedback I get. The D6 and D7 modules both suffer from the implementation being too specific and from being difficult to customize.

The current implementation for D8 focuses on constraints. Allow Overnight, Max Length of Reservation, Office Hours and Conflicts are the current constraints. The idea is third parties can add new constraints and attach them to entities as well as attach the existing constraints to their own entities based on their needs.

To do the D7 to D8 port I currently created a merci_reservation entity and attached the constraints to it. But in the final product I think it is better to create a merci_line_item entity (similar to commerce_line_item). And then have a merci_reservation made of entity_reference field to merci_line_item entities. Plus a custom widget for the field.

Speaking of commerce. To a degree that is the modal. It would be nice to be able to add a date_field to the commerce_line_item type and then add the conflict and other merci constraints. So, commerce_order would then be used for creating reservations and in turn paying for them.

Excuse the above being a bit disjointed. I don't mind being available on freenode in order to chat on how best to move forward.

Comment #9

Josephnewyork CreditAttribution: Josephnewyork commented 24 June 2020 at 21:13

@darrick I'm aware that this issue was last commented 3 years ago, and that's actually why I'm continuing it... I think some things have changed since then in the Drupal Booking world, and perhaps worth a rehash...

Basically in your last comment pertaining to D8 port, you mention that it requires core daterange, you'd like it to support Commerce, etc. Well the module BEE/BAT would handle all of your issues if your D8 MERCI module would solely be a BEE extention, no? Or even create a separate D8 BEE branch. I realize that wouldn't leave a path for a MERCI D7 upgrade, but that decision might not be an issue. Also, you could use the Smart Date module if BEE's date range isn't extendable to MERCI. Just an idea.

I'll help contribute to a MERCI/BEE/BAT D8 all I can if that comes to fruition. Also open to discuss help funding it, as I'm currently building a site using BEE and will definitely need MERCI funtionality when users try to book reservations.

Cheers!
-Joseph

Comment #10

darrick CreditAttribution: darrick commented 30 June 2020 at 19:18

@Josephnewyork I'd be open to exploring that. I'm still on D7 for the most part. But do need a solution when that reaches EOL. I stopped working on the D8 branch because I got tired of waiting for daterange to get into core. I've looked into using BAT in the past. I forget specifically why I didn't think it was suitable. I recall it had some core functionality missing. Mainly regarding bucket reservations.

Anyway, I'm fine with taking a fresh look and considering a new direction. I inherited this module and it's based on work from 12 years ago. I've tried changing the model but I'm more of a under the hood hacker then overall project designer so I quite often get lost in the weeds.

Comment #11

Josephnewyork CreditAttribution: Josephnewyork commented 1 July 2020 at 20:57

Thanks for responding @darrick. Really seems like the folks at BEE are very much actively developing, made an update like 4 days ago, and BAT has D9 in view. Anyways, it's just an idea to keep MERCI moving forward, it's very powerful. I'll be keeping my eyes on your D8 mod, BEE/BAT or not!