Documenting channelAustin's MERCI Implementation
NOTE: There has been ongoing debate as to the best location to post documentation (or even raw documentation as this is), and while www.openmediaproject.org was provisionally agreed upon as the best landing place for this, I feel that GDO OMP may be more accessible and definitely has a wider audience.
IMPORTING DATA: Using the procedures initially outlined in this screencast - http://www.blip.tv/file/4002484/ - I successfully imported equipment data from Facil into MERCI. (Facil is the proprietary software package used by many public access stations to manage resources, reservations, classes, etc.) I posted additional notes on this process here: http://groups.drupal.org/node/93609. And thank you Darrick for helping to resolve an issue that was causing syncing MERCI Inventory fields with content types to take a long time.
COMMENTS ON RESOURCES AND BUCKETS: Part of the import process involves making decisions and designating which equipment items are resources versus which are buckets, where resources are singular items and buckets are content types with more than one item. Without any instruction, I created content types for each resource, rather than grouping resources together under one larger category. So, for example, we have three studios (Main, Mini, and Micro) and I created 3 content types for each. You may say, "so what?" Well the implication is that now when you go to Create Reservation and look at the dropdown menu for Reservation Items, there is a long list that includes the resource content type and the resource item for every resource item. It's a bit ugly. Maybe there is a way to filter those out, or maybe I need to re-create some resource content types and group things more.
MERCI PERMISSIONS: Anyway, once all the EQ data had been imported as bucket or resource content types, the next thing to do was to grant the correct permissions for MERCI content types. I had previously created roles on /admin/user/roles. Remember, here's the logic. A training class results in a certification. A certification grants access to types of equipment. So each one of those certifications (which would be in the CiviCRM side) translates to, or corresponds to, or maps to a role. Here are our 20 roles:
advanced studio tools certification
audio advanced certification
audio certification
avid certification
camera advanced certification
camera basic certification
camera hd basic certification
camera hdz5 certification
camera iyouth certification
dub rack certification
final cut pro certification
glidecam certification
jib certification
kiosk certification
lights certification
studio main hd certification
studio micro hd certification
studio mini hd certification
studio multicam hd certification
studio multicam sd certification
Before doing anything in MERCI, I created an excel spreadsheet with Content Types on the Y axis (column) and Certification Roles on the X axis (row), resulting in a 90 x 20 matrix. Then, based on our current access rules, and with additional help from staff to update thes rules, marked with an "X" in the content types that roles enabled access to. If you don't have that many content types or roles you can probably not have to create this worksheet.
In MERCI there is a Permissions tab on the MERCI configuration page /admin/openmedia/merci/permissions The first problem I ran into is that the 90 x 20 content type - certification matrix goes way off the page. It was very tedious to check the correct box. It took many hours to do this properly. But that was after overcoming the second problem, which was that some of the boxes to be checked would not accept the check. They'd disappear after each save submit. Fortunately Darrick was able to resolve this problem by fixing something at the MERCI module level. Once this was fixed I completed granting the correct permissions.
ACCESSORIES: I wasn't sure what to do about accessories, where accessories are items that aren't necessarily part of the inventory (audio XLR cables, firewire cables, BNC adapters, etc.) because they don't have tag numbers or because they are low cost surplus items. Ann Theis from DOM conceptually explained DOM's use of Taxonomy. And Craig Sinclair laid out some pragmatic steps. Which boils down to create a new vocabulary /admin/content/taxonomy, then associate that vocabulary with the appropriate content types, then add a list of terms.
We have over 50 types of accessories and again about 90 content types, it was time to create another matrix. This time a 90 x 50 matrix. Initially, the idea was we were going to be very specific and exactly identify which accessories are associated with every single content type. But after other staff looked at this on a spreadsheet, it made more sense to create groups. Generally, we noted 4 main types of accessories:
Lighting Accessories
Audio Accessories
Studio Accessories
Camera Accessories
Did a test run and created an Audio Accessory taxonomy vocabulary and added 13 terms for various cables and adapters, and mapped the vocabulary to all the audio related content types, and in the settings made sure to check Multiple Select.
Then, when I go to Make Reservation, complete the form, and click on submit on the next page - the node for that reservation - there is an option to Add Accessory after the specific equipment item. It works. I can add accessories. It'd be good to insert instructions for users on how to do a multi select.
BUT, when I click on the equipment item, it takes me to another reservation page just for that item that has links to the taxonomy terms, and when clicking on those taxonomy terms it leads to pages that says "There are currently no posts in this category." This is taxonomy working as it should but I can see how users who decide to click through links will end up in places that don't make sense. Would be good to close that off. Maybe in a non-admin mode it would.
Suffice it to say dealing with accessories is sort of uncharted territory and we're not done with this part.
MERCI VIEWS: There are several Views that need to be modified for MERCI. A few come with MERCI. Others are add ons.
Out-of-the-box when you install MERCI you should find the View merci_inventory. I was having some trouble with this at first, getting an error message when going to /admin/merci/manage/inventory I found that in Views for merci_inventory I had to un-do, then re-do, the filter, and the error went away. This may have been specific to my installation and not a universal problem.
I would recommend choosing the fields in Views that you want exposed to best suit your purposes. The out-of-the-box fields are not sufficient.
Another important View is for Reservations. Actually it is merci_reservation_calendar. I haven't noticed a need to edit this, but it does need to be exposed to the Navigation Menu.
Looking on Amherst's site I notice there is another Reservation view that is different than the calendar. I'm still waiting to hear from Craig what this one is for.
There are also Views for Reports that aren't associated with the Module but that can found here: http://www.openmediaproject.org/code
Kevin has made a screencast that describes these: http://openmediaproject.blip.tv/file/3970704/
COMPLETING THE MERCI IMPLEMENTATION PROCESS: Besides finishing with the Accessories section and getting better clarification on the Reservations View, we're almost finished with implementing MERCI.
The really big next step is integrating with CiviCRM, or rather getting our data updated and correct for users in CiviCRM. Specifically getting certification data working in CiviCRM and making sure that is all synced properly with the certification roles in Drupal.
Once we do that, then we can actually start using MERCI for reservations. We'd like to start first with staff doing it to test it. Probably running MERCI in parallel with Facil for awhile.
QUESTIONS MOVING FORWARD
-
Best practices for getting class certification data into CiviCRM?
-
How to make the transition over from Facil to MERCI?
-
Best practices for staff running MERCI while making the transition to users?
-
We have a conundrum. There's a class called TV101 that doesn't enable any particular content type, but all content types. In other words, until a producer has completed TV101 (or an earlier variant of the course called Program Warranties) they are not able to make any reservations or submit any programs. But they don't have to take TV101 before taking any other classes. So they can have certifications in classes, but if they haven't taken TV101 can't make reservations. I suppose one solution could be that a user cannot create a project until TV101 was taken. Because without a Project reservations and programs cannot be submitted. But there is an argument to be made for being able to create Projects for other purposes.
-
Wondering about limits on multiple item reservations. As it stands, does MERCI limit the ability for someone reserve more than one instance of the same item?
Comments
No limits on items
Found this open issue
http://drupal.org/node/810068
And Ann Theis from DOM responded to a query confirming there is no way to stop someone from reserving 2 or more cameras of the same type.
In this case, it'd be good to add text to the Make Reservation form regarding the limits of gear, or have a link there to a policy and rule page.
Regarding creating content
Regarding creating content types for each resource. A good way to decide this is thinking about it in terms of permissions. You can only set permissions per content type not per item. So it was smart you created different types for each studio as there are different roles for each. If you just had one studio certification which allowed the user to reserve any of the studios then you would need only one studio content type.
For the TV101. Map this role to the "create reservations" permission to toggle that off and on. If a user has the "studio main hd certification" role which allows them to reserve the main studio they still won't be able to do it unless they have the "create reservations" permission.
that's smart
So ONLY have one role -- TV101 -- connected to "create reservations" and leave all the others off?
Grouping
I did not implement Grouping in MERCI Inventory. This would influence the appearance of the drop down menu for EQ to be checked out.
I'm traveling the rest of
I'm traveling the rest of this week and part of next week, but a few quick things...
1) When a station or school's policies are too complicated to implement in MERCI, use the option to create Unconfirmed Reservations and create a View for staff to quickly review those and move them from Unconfirmed -> Confirmed.
2) My advice for implementing self service reservations with MERCI or migrating from Facil to MERCI with a staff managed workflow has always been the same... start slow. Enable one certification and one type of equipment and then build on that. Start with something like equipment available with studio certification. Let your members know they can now make studio reservations online. Once you get that working well, enable another certification and group of equipment.
3) While you can use accessories however you want, the idea was to provide a checklist of items the user might often need with the main item. In the university checkouts I ran, I required my student employees to open every kit and check for things like lens caps when the kit went out and came back. If the kit came back without a lens cap, but the student returning it swore it was missing when they took the kit we addressed it right away.
If I was checking out a Lowell Light Kit it would make sense to check to see if I also wanted a Light Lowel Gel Frame or Light Lowell Bending Arm. But if I was checking out an iMac, I wouldn't include those.
Multiple Accessory Taxonomies can be associated to the same Content Type. My recommendation is to start with the obvious. Create an Audio Accessories, Cables, and Lighting Accessories and enable them to the appropriate content types.
If you find that users who are checking out the Studio Fog machine often want a USB cable, add that option.
Also, users making Reservations can't add Accessories. That is limited to staff checking the gear in and out, Hopefully, there's no need to explain multi-selecting to that group.
4) Dealing with TV-101. When you have paid membership and certifications impacting a user's permission, this gets really confusing and the lack of smart group support in synchronization makes it hard to implement. Normally I grant permission to the Reservation and Project content type based on Roles mapped to membership and control access to the equipment within the Reservation based on Roles mapped to certification. The way CiviCRM synchronization works now, it isn't an additive process. The last check either adds or removes the user from the Role. So if you check membership first and TV-101 second, users with expired memberships but TV-101 certification would still have access to make reservations.
You could add role that is NO TV-101 and assign the Suspend MERCI permission to that Role. Users in NO TV-101 will not be able to make Reservations even if they had an active membership that normally allowed that at the content type level. Once they are removed from that NO TV-101 role all of the certifications and membership checks would still be in place.
What about NO TV-101 for Create Show?
channelAustin also has a policy that a member-producer cannot submit programming (i.e. Create Show) until after completing TV-101. There is no Suspend option for Create Show, so we'll need a different solution than what's above.