cod_bof view should work with single column sessions schedule and tabs

patch applies clean, tabs are now showing on the bof schedule/scheduler

patch applies clean but page schedule for bofs doesn't display for authenticated users only. We need it displayed for authenticated users to allow them to create bof sessions.

and I think "program/bofs" should be moved to cod_bof.module menu instead?

Here is my attempt at this (used patch from comment#1)
- set the program/bofs permission to "access content"
- moved the said menu in cod_bof.module

forgot the status

Looks like cod_session shows overrides after applying the patch to da_drupalcon sandbox. I'll clean it up . . .

Should be identical to #5, except cod_session should now appear as default. I tested the BoF scheduler and overlaps are avoided; available (and full) timeslots are listed on a beautiful tabbe program schedule; data is autofilled when a bof is created when a user clicks on an open time slot. Hopefully Features will cooperate this time, because everything else is probably good to go.

unassign

Patch applies clean, functions as expected!

works as described.

3 good reviews, I'm going to put this in the sandbox.

this has changed dramatically with the new implementation of the tabs.

1. The quicktab format used in the session views will only work with pre-defined timeslot and room. the bof page dont have them yet and instead we create links for every available room and timeslot so I don't think this format will work for Bofs.
2. with the recent change in the session tab display, the cod_schedule_display variable was committed (unintentional?). Not sure what the plans is for that. the variable cod_schedule_display is in use in the tpl file too.

I marked #1661620: Authenticated Users Cannot Create BoFs Regardless of Permission Settings as a duplicate of this.

@brantwynn Yes, I suggest following that approach.

I've re-rolled from #1661620- to give us a good baseline to start our on single column view

Working on adding flags and adding back the work done by brantwynn to get the single page done.

Here is some more patch work, starting with a new flag for indiciating if a timeslot or room is able to have a bof in it.

its not complete, but if someone wants to work on it tonight and post an update by the morning -- go ahead!

one other thing you might want to work into this patch, disabling the room and timeslot fields on the node/add form after the prepopulate values have been entered.

Here is a patch that comes after the first one in #21. must apply 21 first, then this one.

This gives bofs a single column quicktab layout, found at program/bofs

Its not complete but should be a little further along. Dyannenova said she will take a look at making the markup a bit prettier.

Sweet!

Patch applies clean. program/bofs is going straight to the tabbed display :) Time slots that are flagged for BoFs are showing up, those *not* flagged do not show. All rooms are showing at this time though. Fantastic improvement!

starting with a new flag for indiciating if a timeslot or room is able to have a bof in it.

COD_BoF already has capacity fields that are used to determine this. Can you clarify whether the new flag would be redundant or not?

I don't think the capacity field fulfills the need here. Just because a room can only host one session/bof does not necessarily mean that it will only host a session. This flag is definitely needed on the time slot though, as currently the scheduler assumes that all available time slots can be used to schedule a bof.

I agree that the capacity field doesn't define what type of content can be in that room. Designating allowed content that can occupy a time slot is useful when scheduling controls can be given out to other roles.

For DrupalCon Denver authenticated users could schedule BoFs during limited times a day, instead of all available time slots. This was accomplished by a text select field on the time slot node type that allowed the (unfortunately custom) BoF scheduler to provide only certain time slots for use.

Thanks for weighing in, coltrane.

I agree that a field makes more sense than a flag, since we're exporting data that describes the timeslot, rather than data that refers to it.

I think the room should also have that field.

I think both should default to false.

After applying the last patch I'm not seeing any of my rooms or times in the scheduler at program/bofs

sweet! It works!

patch applies clean, only rooms and times that are set to allow BoFs show in the scheduler :)

Some house-keeping items:

• make the time label a single line
• when a session is schedule for a room/time (that bofs are also allowed in) have it show 'No slots available', or just remove altogether. Currently it shows the room name with no associated info.
• Have room labels above the BoF titles/availability info.

As discussed in IRC, here's what I'm seeing:

The first time slot in Room 1 already has a session assigned to it. While it is not available for scheduling a BoF, we're just trying to indicate that the room has no available slots at that time.

Patch applies clean, scheduler functions as expected. Can add sessions to available slots, but not to a room/time that has a regular session scheduled. Looks good to me :)

Works on my end as well. Layout tends to mess up when there's too many time slots though.

Oops, miss the screenshot.

spammer cleanup...

japerry, DyanneNova, mrconnerton and myself discussed this functionality at the Distro sprint at DrupalCamp Asheville. Here's some documentation of the results of that conversation:

1) The re-written COD_BoF feature proposed in #40 adds ~900 lines of code on the schedule tpl.php file versus what was included in the Drupal 6 version. This is mostly business logic that should exist in the module layer if possible, rather than the theme layer.
2) http://drupal.org/project/views_field_view likely makes it possible to configure elements of the vertical scheule which were implemented via the theme in #40.
3) Some conferences (such as LinuxFestNW that has been the motivation for COD contributions by japerry and DyanneNova) have a session scheduling workflow where a higher tiered session organizer first blocks out the schedule to specify which types of sessions can happen during certain parts of the schedule (eg, a room that has a keynote from 9-10 but then should allow only BoFs from 10-4).
4) A proposed UI for implementing #3 would add a control such as "Alllowed in this slot: Bofs" or "Allowed in this slot: Sessions & BoFs" to slots in both the vertical and grid schedule views. When engaged, this control would allow the more permissionsed session organizer to specify which types of scheudulable items are allowed in that room during that timeslot. This information could be stored in a field collection on the room node (such as room_slot_types_allowed) that would contain an entity reference to each timeslot, and a set of checkboxes for each of the schedulable types that can fit in the room during a particular timeslot. So, when editing the room node, you might see something such as:

Schedule settings:
-- 6/15/2013 10:00-11:00. Allowed in this slot:
[] Sessions
[] Schedule items
[] BoFs
- 6/15/2013 11:00-12:00. Allowed in this slot:
[] Sessions
[] Schedule items
[] BoFs

Hi Brant,

I agree points 3 and 4 from #60 shouldn't delay this issue getting resolved. I've filed #1742806: Ability to designate which types of schedule items fit into a slot for that feature request. The original reason for including it here is that it sounded like japerry and dyannenova were close to filing a patch that both resolves the present issue as well as that new functionality. I'd still accept such a patch and mark #1742806 as a dupe, but until/unless such a patch is produced, I agree that it shouldn't hold up this issue.

With regard 900 additional lines of themeing code, compare the cod_sessino.tpl.php (54 lines in Drupal 6) with what you're proposing in #40.

In its current state, yes it's not very pretty... but there are conferences with sites in D7 that need this to work yesterday.

I can understand that it's frustrating to re-roll a patch that hasn't yet reached RTBC, but separating functionality from presentation is a fundamental programming pattern that Drupal observes, and we'd be doing a disservice to COD and it's user base if we abandon that pattern. I don't see the benefit in the approach of committing something we know is fundamentally not aligned with best practices with the goal of refactoring it "later."

Regarding

refactoring/rewriting COD into a lighter and faster system that is accommodating to a wider variety of conferences

, do you have specific suggestions for what that refactoring would look like and areas COD should be more performant?

So I proposed ~38 new lines of code when I refactored session.tpl.php to work with both BoFs AND Sessions.

Re-examining #40 I see that I misread the patch and that the code I was including in the 900 lines is actually added in a preprocess function rather than the .tpl.php file. I apologize for misreading #40. I agree that in general a preprocess would preferable to code in the template file, though less preferable than a solution that assembles the schedule in a structured way that happens separately from the theme layer.

japerry has filed an initial patch at #1742806: Ability to designate which types of schedule items fit into a slot that provides an alternative solution for the COD schedule system that would eliminate the need for this preprocess code entirely, and has committed to revising it by Friday.

I recognize the importance of having the COD scheduling system take more definitive shape, and that you've been working on this issue for 3+ weeks. As a result, I'm committing to review the work at #1742806 with the goal of having a commit towards the bof/schedule system by the end of the week.