Ability to reference a time slot or available appointment - only once (Ideas??)

Did something like this for a yearly conference a few years ago. Every time slot was a node and there was an entity reference field to the sessions that only allowed for one node to be connected (using views we would show/hide the 'add session' link based on the existence or not of that reference)

we also had locations (buildings and rooms) referenced to the time slots and profiles of the folks presenting referenced to the sessions.

this way we could use views to show daily schedules; schedules by room. There was a plan to have a view on each person's dashboard so they could mark what sessions they were interested in on the schedules and see their personal schedule

I might still have the code lying around if it's useful.

I thought it would be fun to put together a small demonstration of this today using the references, views, date and rules modules, but no php coding.

In a nutshell, create a 'slot' content type that has fields for date, start time, end time, unique title & user reference. Create a node for each session slot, leaving the user references blank.

To control access I created a manager and a volunteer role and added some users with those roles. Mangers can add/edit/delete slots, volunteers can be assigned to slots, view a list of their appointments, assign themselves, open spots and remove assigned slots. 

Create a view with displays for listing volunteers. Create a view for listing slots, unassigned slots, assigned slots and slots assigned to a user.  Add links to allow user to assign and unassign from a slot.

Create a view for volunteer's profile tabs that shows their current assignments. Embed another view in the footer that shows available slots.  Add links to cancel and add assignments by linking to node/[nid]/assign and node/[nid]/unassign, which will be handled by a pair of rules.

Create rules to assign and unassign the current user from a given slot.

Here is the overview of the "assign" operation rule. Basically, when a volunteer visits a slot page with the word assign appended, we check that the slot is unassigned and fill the slot's user reference field with the current user.

It was fun figuring out how to do this without any programming, although that would be my preference instead of using rules.

There are lots of details as to how to configure the views and rules, but nothing very tricky. Things like handling access, menus, formatting, tokens, etc.

This is just a simple approach for use with limited sessions, e.g. conference sessions. For repeated daily slots such as for office appointments, separate slot and appointment types make more sense and add a little to the complexity with forward and backward references between 'slots' and 'appointments' but could still be built in a similar manner.

I hope this helps.

I set up another example, this time with two content types as you describe. 

No programming is required for this.  In fact, you don't even need the 'taken' field! :)

Just use a (reverse) reference view for the session nodes' time_slot field.

This is simply a view of all time_slots that do not have a session referencing them. This view has a 'reference' display instead of page or block so that it can be used as a lookup for select options on the session node add form.

Here is the view, with the important options set:

Here is the field def:

Here is the result when adding a second session after I had already taken Time Slot A:



Oops! I forgot to reverse the default sorting in the view! Easy fix!

Along with the simple filter, it's the reverse relationship in the view that makes this all work. The "reverse" option on relationships appears when you add one to a view:

The same technique could be used to display the "taken" status on a time_slot node's display without there actually being a field.

Alternatively, a rule or code could watch for changes to session time slot fields and use the reference to update a time_slot node's taken field if you must have one.  Rules and callbacks have access to old and new values when triggered by a field change. Use those to find the appropriate time slot and set or unset it's taken field.

I hope that applies to your approach.