CUNY Academic Commons

I'm having a conversation with GC Digital Fellow Keith Miyake about this and we would like to have the fellows collaborate on this project this year. He is now a watcher on the ticket and we will get back to the Commons team with some ideas.

I know that Christian is building a BuddyPress addon plugin for the popular Event Organiser plugin. Event Organiser is probably the best event plugin available from a code standpoint and is something I have wanted to integrate with BuddyPress in the past.

Might be a good chance to review what Christian has done and whether it might be suitable for this ticket.

I've started looking into the existing calendar plugins out there. It's somewhat overwhelming, as there are many such plugins, and it'd take weeks of review to get a real sense of their relative strengths and weaknesses. That being said, here's a rough list of desiderata:

1. Plugin should be well supported by its core developers, and ideally the plugin code itself is pleasant to work with
2. Ideally, it would already have some BP integration: with activity stream, with groups, with user profiles. Group integration should allow multiple group associations per event.
3. It should have reusable event-view templates (or template functions), including a calendar view
4. It should have reusable event-creation templates and controller logic
5. Access control (private vs public) for specific events
6. Recurring events
7. Event attendance (Yes/No/Maybe) linked to logged-in user (so we can build BP component for displaying this info)
8. Data storage and retrieval model should make sense and be extensible. Eg, it should be easy to modify the basic queries so that we can pull up only those events belonging to a group, or only those events that are private, or whatever. If the plugin uses custom post types for storage, then we have access to 'pre_get_posts' and other core hooks for this purpose.

With these criteria in mind, I've looked at a few options:

A. Event Organiser https://wordpress.org/plugins/event-organiser/ I started here because Ray mentioned that Christian had started work on BP integration for this plugin https://github.com/christianwach/bp-event-organiser. EO seems to be a pretty decent plugin, and Christian's plugin is a decent start on integrating into BP, though for the Commons we could probably do away with much of the Groups Hierarchy stuff and put some more focus on building a more flexible group/event connection (maybe a taxonomy that'd prevent two-way queries, rather than an array in postmeta). I'm somewhat concerned about the reusability of EO templates, both for calendar view (which appears to be hardcoded in various places in the function) and for event creation/editing. Christian, do you have any thoughts about the challenges here?

B. Events Manager https://wordpress.org/plugins/events-manager/ This plugin is interesting because it already has BuddyPress support. However, the BP support is too limited for our purposes. It looks at a glance like event content is mirrored between a custom post type and a custom table; group_id is a field in the custom table. This means that native support is only for a single group association per event. There are also some hardcoded restrictions on the connections between group status and event status - for instance, it appears that a private group cannot have publicly listed events. I think we'd probably have to unhook the BP functionality and build our own. The core plugin doesn't appear to be very extensible, in terms of either templating functions or queries.

C. The Events Calendar https://wordpress.org/plugins/the-events-calendar/ At a very quick glance, this appears to be the best written and organized of the plugins, at the level of the codebase. Views are abstracted out, with support for template overriding in themes. It appears that they have one-liners for, eg, pulling up a "month" view (`tribe_show_month()`). I assume we'd be able to use much of this for the display of events (though editing/creation does appear to depend on the Dashboard). Data storage uses CPTs and WP_Query for retrieval. Ray mentioned something about how this plugin didn't have great support for recurring events - Ray, can you say more about this? Would it make a difference if we ponied up for the Pro license? https://theeventscalendar.com/product/wordpress-events-calendar-pro/?source=tri.be&utm_medium=plugin-tec&utm_source=readme&utm_campaign=in-app

See also https://buddypress.org/support/topic/no-all-in-one-event-calendar-plug-in-for-buddypress/, which is the most thorough review I've seen of BP compatibility with popular WP calendar plugins (though from a non-dev point of view).

Based on this review, my inclination is to do some initial tests using The Events Calendar, to see how easy it'll be to reuse their view templates, and to integrate into BP. Regarding front-end event creation/editing, I have a feeling that regardless of the plugin we choose, we're going to have to build a fair amount from scratch, so IMO it's not a distinguishing factor between plugins.

Thoughts or experience from others would be most welcome.

Ray mentioned something about how this plugin didn't have great support for recurring events - Ray, can you say more about this?

TEC's recurring events functionality requires purchasing their PRO version. Having worked with The Events Calendar PRO recently to build an iCal importer for a site, I can say that recurring events support isn't so great. They create a new post for each recurring event. Let's say that an event is repeated infinitely, TEC will create hundreds of new WP posts. Event Organiser handles this better by recording one WP post and the rest of the recurrence data into a separate table.

Event Organiser (EO) covers most of the points listed in Boone's list of requirements:
1. Code - Uses a function-based approach, so it's simplistic in that manner.
2. BP integration - None. Shouldn't be too hard to pull off. Need to do an audit of Christian's plugin.
3. Template functions - EO uses a version of the template stack similar to BP and bbPress, so it'd be easy to intercept templates. EO also has shortcodes and template functions to output calendar views so it'd be easy for us to add a calendar view that way.
4, 5. Event creation - See includes/event.php. EO does offer a plugin to do frontend posting, but it's an upsell plugin or included when purchasing their developer license. We could probably build this ourselves. EO registers two taxonomies - categories and tags - so we can probably add in our group data that way, or use their event meta table. Eventmeta might be better so categories and tags can be agnostic to groups.
6. Recurring events - Doesn't require PRO. Data schema is better than TEC.
7. Event attendance - This is a PRO feature (http://codex.wp-event-organiser.com/function-eo_get_events_user_is_attending.html). But I'm guessing EO is just recording user information into their event meta table. We could do this ourselves if needed.
8. Event retrieval - Uses CPT and WP_Query.

Also has unit tests:
https://github.com/stephenharris/Event-Organiser/tree/master/tests

If we wanted EO's PRO version, their license is yearly recurring, so we'd have to renew our license yearly. I don't think that PRO is necessary, but might speed up development.

If we're comparing EO to TEC, TEC requires PRO for recurring events and I don't believe TEC has event attendance.

Boone, let me know you think.

Ray, thanks so much for your valuable thoughts. I largely defer to your practical experience here. Your arguments in favor of EO sound pretty convincing to me, especially your notes about template functions, which I think I missed in my brief scan through the plugin.

I would assume that getting PRO versions or other paid addons (like the one for front-end posting) is a non-issue, particularly if it's a one-time fee. Perhaps Matt can confirm. (We're probably talking in the low hundreds in license fees, all told.)

Regarding group affiliation. I think it'll be important to allow for many-to-many relationships that are easily queryable - which groups are associated with a given event, and which events are affiliated with a given group - and for this reason, a taxonomy seems best. Let's just register a custom one, and leave their tags and categories alone. Whoever ends up building this, I'd be glad to help sketching this data model.

Before making a final decision, I'd like to hear from Christian, as he has clearly done some work with the plugin. I noticed some unpleasant looking hacks in my brief look through his Github repo - it looks like displaying calendars required some weird transient cache busting. Christian, any dealbreakers that you've run into in your experience with EO?

Boone Gorges wrote:

A. Event Organiser https://wordpress.org/plugins/event-organiser/ I started here because Ray mentioned that Christian had started work on BP integration for this plugin https://github.com/christianwach/bp-event-organiser. EO seems to be a pretty decent plugin, and Christian's plugin is a decent start on integrating into BP, though for the Commons we could probably do away with much of the Groups Hierarchy stuff and put some more focus on building a more flexible group/event connection (maybe a taxonomy that'd prevent two-way queries, rather than an array in postmeta). I'm somewhat concerned about the reusability of EO templates, both for calendar view (which appears to be hardcoded in various places in the function) and for event creation/editing. Christian, do you have any thoughts about the challenges here?

I think Ray has already covered most of the bases with Event Organiser (thanks Ray!). It's a nicely written plugin and Stephen Harris is responsive to issues on GitHub, which is a bonus. For example, Boone, you might remember the recursive hook issue we ironed out between EO and BP Docs. I haven't used the paid-for add-ons, so can't comment on that aspect.

Regarding my BP Event Organiser plugin, one of the reasons I haven't published it on the WP repo is that I wasn't entirely happy with its behaviour - particularly (as you already identified) the cache-busting that has to take place every time a group calendar is viewed. I guess this can be worked out, but it might need an "upgrade" to cache handling in EO. My memory on this is a little shaky as it's a while ago that I worked on it, but I don't think it's a deal-breaker.

I should also mention my CiviCRM Event Organiser plugin https://github.com/christianwach/civicrm-event-organiser which syncs EO events with CiviCRM events. I really must find some time to work on this plugin because CiviCRM is just about to introduce native recurring events - it was this shortcoming which was the primary reason the plugin was developed. Oh, and because CiviCRM currently has a horrible UI for events, whilst EO has a really nice one!

EO and both of my plugins are installed on IHC, so if you want to have a play around with them, it's best to do so on the dev site http://dev.islamichistorycommons.org/ - but please give me time to sync live to dev before you do... I should be able to to this today. (Update: sync completed)

Regarding the other plugins: I haven't used TEC myself, though I know many people in the CiviCRM community seem to like it. I didn't enjoy working with Event Manager when I had to - I wasn't that keen on the way the code was written, theming it wasn't much fun and I also wasn't keen on the UI and workflow.

For completeness, I should also mention BuddyPress Group Calendar https://premium.wpmudev.org/project/buddypress-group-calendar/ which is non-free. I've used it before and it's okay, but has no support for repeating events or assigning events to multiple groups.

tl;dr Of the plugins mentioned I like EO the best and would be happy to assign BP Event Organiser to the CUNY org on GitHub if it's chosen as the starting point for integration.

Thanks very much, Christian. This is all convincing enough for me - let's go with Event Organiser. (Notwithstanding that it will be hard for this American to remember that it's spelled with an 's' :) )

It sounds to me like starting with the Pro version will do a bunch of the work for us. Matt, can you confirm that this won't be a problem? http://wp-event-organiser.com/pricing/ £40 per year, which we can stop paying if we decide we don't need updates.

Here's a first, high-level pass at a spec. Some of this is already done by Christian's plugin. I'm going to suggest that, for now, we work off a fork of Christian's plugin, as I don't want to be hampered by backward compatibility to IHC and other installations where it's in production. If I could ask everyone (especially Ray, Christian, Samantha, and Matt) to read this over, we can chat about it - and start to dole out the work - during Tuesday's dev chat.

1. Group integration

a. When creating or editing an event, it should be possible to link an event to one or more groups. A custom taxonomy is probably best to handle this, so we'll need some wrapper functions in addition to the necessary UI. UI can probably be a multiselect box or something like that for now, but we could do some nice ajax/autocomplete stuff if we have time.
b. Let's make sure to abstract something like a 'associate_event_with_group' permission. It's highly likely that, in the medium term, individual group admins will want the ability to control who can associate events with their groups. We probably don't need to build this UI for v1, but it would be nice to build v1 with this in mind.
c. A BP_Group_Extension tab that displays group-linked events. Would be nice to have the choice between calendar and list view - I assume this is built into EO.
d. On individual event pages, display a list of groups that the event is associated with.
e. Ideally, it will be possible to view individual events within the group context - that is, inside of a group tab, with a URL commons.gc.cuny.edu/groups/my-cool-group/events/my-awesome-event. I know this will be a serious PITA, because events are not essentially linked to groups, they can be linked to more than one group, etc. But my experience with BuddyPress Docs is that users are befuddled when they don't see the group wrappers and they think they're supposed to be in the group "context".

2. Front-end event editing/creation

- It should be possible to create/edit events from the BP interface. We don't necessarily need to have 100% feature parity with the Dashboard interface, but we'll at least need nice UI things like datepickers.
- Create interfaces should appear in the group context (nav, URL) when event creation is triggered from within a group. (Ie, there will be a "create event" button or tab in groups, and when clicked from there, you'll go to /groups/foo/events/create or whatever.) Event creation that is triggered from elsewhere (user profile, top-level /events page) will be in a "global" context (presumably, /events/create or something like that). Event taxonomy and map integration would be super great if possible.

3. User profile integration

- Individuals will want a way to view a calendar of their own upcoming events. Let's put an Events tab on user profiles, and let's make it visible only to the displayed user.

4. Event visibility

- Default status for events should be public.
- People are going to want to have non-public events. Generally, I assume that "non-public" will mean "visible only to the members of the associated group". This suggests a simple toggle. It gets more complicated if people associate items with more than one group. But I say that for now, we don't worry about that. Either you have a public event, or one that's visible only to members of associated groups. Samantha, your thoughts on this would be welcome.

5. Activity stream integration

- Creating, updating, deleting events should create BP activity items
- Because items will be potentially associated with multiple groups, my initial thought is that we should create separate activity items for creation (which would be 'hide_sitewide=false' for public events, and be unassociated with groups) and for group associations. So, creating an event "My Cool Event" and associating it with groups Foo and Bar would result in three activity posts: (1) "Boone created a new event My Cool Event" hide_sitewide=false; (2) "Boone created a new event My Cool Event in the group Foo" group_id=foo_id hide_sitewide=true; (3) "Boone created a new event My Cool Event in the group Bar" group_id=bar_id hide_sitewide=true. This will ensure that BPGES notifications trigger correctly. Alternatively, we could create single activity items for new events, and then try to mess with BP 2.2's new complex activity queries to show them in the streams where they belong; my sense is that this will be a lot trickier (if only because there are so many streams), but Ray, it'd be helpful to hear what you think.
- These should be "minor" activity items from the point of view of GES. You should get them if you subscribe to "All" in the group, or the Daily digest.

Thanks for putting together such a comprehensive overview, Boone. Sorry I wasn't on the Tuesday call to discuss it. Some thoughts/questions:

1. b. Let's make sure to abstract something like a 'associate_event_with_group' permission. It's highly likely that, in the medium term, individual group admins will want the ability to control who can associate events with their groups. We probably don't need to build this UI for v1, but it would be nice to build v1 with this in mind.

Yes, I think some kind of 'Does your group want to be associated with this event?' approval process would be helpful, whenever it's able to be integrated.

3. User profile integration: - Individuals will want a way to view a calendar of their own upcoming events. Let's put an Events tab on user profiles, and let's make it visible only to the displayed user.

Will "their own upcoming events" include all events for groups they belong to? Since we aren't attaching a ticketing/RSVP functionality (right?), it may make sense to add some kind of hiding option or a way to opt out of seeing events for certain groups. That way users can see just the events they'd like to attend in case they belong to groups that post lots and lots of events.

Am I correct that events cannot be created by an individual user, they have to be created within a group and associated with at least one group?

Event visibility: - People are going to want to have non-public events. Generally, I assume that "non-public" will mean "visible only to the members of the associated group". This suggests a simple toggle. It gets more complicated if people associate items with more than one group. But I say that for now, we don't worry about that. Either you have a public event, or one that's visible only to members of associated groups. Samantha, your thoughts on this would be welcome.

I agree with your toggle idea, Boone. All associated groups should be included when it's "private" and everyone on the Commons when it's "public".
Does this imply that there will be an events tab in the main navigation that leads to a full calendar of all public events?

5. Activity stream integration

I assume these activity notifications will appear in My Commons as well. I think something like "Boone created a new event My Cool Event in the group Bar" should appear in both the 'People' filter and the 'Group' filter. If we are going to have an 'Events' tab in the main navigation, we could add an 'Events' filter within My Commons too.

Will "their own upcoming events" include all events for groups they belong to? Since we aren't attaching a ticketing/RSVP functionality (right?), it may make sense to add some kind of hiding option or a way to opt out of seeing events for certain groups. That way users can see just the events they'd like to attend in case they belong to groups that post lots and lots of events.

Hrm. I hadn't thought about this. I don't think we plan to have a ticketing feature the first time around - this introduces lots of complications involving moderation, ticket sales, limited seating, waitlists, etc. Much easier would be a simple button that says "Add to my calendar". It'd basically be like a bookmarking mechanism, and the results would be totally private - so it could be used to say "I'm attending" or "I'm interested" or whatever the user wants it to mean. Then an individual's calendar would show only those items. The downside of this would be that it'd be complicated to reconcile with any future "attending" or ticketing system - how would the two interact? Perhaps it's easier to skip the question for now: user's calendar view (similar to My Commons) would show (a) a user's own created events, (b) events from a user's groups, and (c) events created by a user's friends. Then we'd have checkbox toggles to turn them off/on in javascript, like Google Calendar has for different calendars. What do you think?

Am I correct that events cannot be created by an individual user, they have to be created within a group and associated with at least one group?

There's no technical reason for this limitation. I'd been thinking that event creation would be technically independent, so users could create their own events.

Does this imply that there will be an events tab in the main navigation that leads to a full calendar of all public events?

I was thinking yes. Doesn't necessarily have to be part of rev 1, I guess.

If we are going to have an 'Events' tab in the main navigation, we could add an 'Events' filter within My Commons too.

Yes, and in other places where activity filtering takes place.

Perhaps it's easier to skip the question for now: user's calendar view (similar to My Commons) would show (a) a user's own created events, (b) events from a user's groups, and (c) events created by a user's friends. Then we'd have checkbox toggles to turn them off/on in javascript, like Google Calendar has for different calendars. What do you think?

Looking ahead to possibly adding attendance/ticketing system, I think you're right to avoid any kind of bookmarking mechanism for now. The toggle option is a good idea -- we then have the option of adding an 'events I'm attending' filter if/when the RSVP system is added.

Having an events tab and the associated logic you describe sounds good. Looking forward to seeing this in action!
Let me know if I can provide any mock-ups in advance.

Hi All,

Sorry to be absent from this conversation so far, but thank you all for making such great and detailed headway. In today's dev call, Boone asked me for a gut check on the direction of developments so far. That gut check is a resounding yes -- I'm excited about where we are going and the many questions being raised throughout. No worries about purchases of any Pro subscriptions needed

But my experience with BuddyPress Docs is that users are befuddled when they don't see the group wrappers and they think they're supposed to be in the group "context".

Very much agree with this and I am glad to see that we are thinking of ways to show/create content both within and outside of groups.

3. User profile integration
- Individuals will want a way to view a calendar of their own upcoming events. Let's put an Events tab on user profiles, and let's make it visible only to the displayed user.

Just want to flag this as a potentially tricky UX issue given our current state of portfolios/profile info. Maybe integrating into the Top Site Navigation in some way would help, too, since we seem to be consolidating a lot there.

At any rate, great work on all of this and many thanks.

One more thing, just to put it on the radar: with the caveat that we want first to get this going on the Commons and then think about abstraction, and with the complication that we are building on an existing plugin, let's think about a possible path towards eventually releasing this as a WP/BP/CBOX plugin -- even if such work needs to be supported by, say, a grant.

I've made quite a bit of progress on my end.

You can now view single events within the Groups frontend interface. You can also edit events within groups. The edit interface and metabox code is directly ported over from the WP Post admin page to the frontend. This means we get most of the metabox functionality pretty much for free. Currently supports editing event details (dates, occurrence), categories, tags and group association (group association uses the existing metabox code).

Here's a screenshot - http://i.imgur.com/kvbhgmN.png

I plan on working on the group "Create Event" page and also deleting group events. For the "Create Event" page, I think we shouldn't add this to the group creation process. It is highly unlikely that when someone is creating a group, that they'll also want to create an event at the same time. Will probably add a button on the single group events page.

Besides comment 11 (#1237-11), these tasks can be divvied up:

• EO's calendar transient caching needs tweaking - EO's calendar caching doesn't really account for variable views and mostly assumes that calendars are static and never changing before invalidation. EO core needs to be modified to properly support queried calendar views. Or we could bypass EO and add our own calendar rendering functions.
• Support taxonomy archive view under group events (example.com/groups/test-group/events/?category=foo, example.com/groups/test-group/events/?tag=foo). This issue came about because if you're on a single event within a group, if the event is categorized and tagged, some taxonomy links will be shown. Currently, these links default to the main EO taxonomy archive page (example.com/events/category/foo/).
• Overhaul BP group metabox - Once Boone is done with the group schema, the existing BPEO groups metabox needs to be tweaked.
• Proper group access control functions - Hook into EO's meta caps and provision according to group member role.

Whoop! Thanks, Ray. I've made some progress too. Event-group links are now many-to-many, powered by taxonomies. Functions for manipulating these connections are at https://github.com/cuny-academic-commons/bp-event-organiser/blob/master/includes/group.php. I've set up a phpunit rig, and you can add tests as desired in https://github.com/cuny-academic-commons/bp-event-organiser/tree/master/tests/phpunit/tests (funky bit: I had to choose between extending `BP_UnitTestCase` and EO's. I chose BP's, which means that the event factory is at `$this->event_factory->event`.) Controller logic in bp-event-organiser-eo.php has been mostly pointed toward the new functions (though there is definitely some cleanup to do there) so that basic group association/deassociation is working on the front- and back-ends.

The edit interface and metabox code is directly ported over from the WP Post admin page to the frontend. This means we get most of the metabox functionality pretty much for free. Currently supports editing event details (dates, occurrence), categories, tags and group association (group association uses the existing metabox code).

I'm sure you tried this and rejected it for a good reason, but: Why not just bootstrap wp-admin?

For the "Create Event" page, I think we shouldn't add this to the group creation process. It is highly unlikely that when someone is creating a group, that they'll also want to create an event at the same time

+1

Will probably add a button on the single group events page.

Yes. I assume the URL will be something like /event/create. Make a note that we should check event slugs against a blacklist that includes protected terms like 'create'.

Or we could bypass EO and add our own calendar rendering functions.

Ick - it would be nice to avoid this. Christian, you said that Stephen is happy to accept PRs, yes? Let's request, at the very least, a filter on the transient keys.

Can we start spinning some of these tasks off into separate items? Today I created an issue on the github repo instead of here, without really thinking. Github issues are quite a bit more lightweight (the thought of creating two dozen small Redmine issues makes me wanna keel over), so maybe we want to use them until we're ready for the CAC team to start giving feedback? Ray, Christian, do you have thoughts about it?

I'm sure you tried this and rejected it for a good reason, but: Why not just bootstrap wp-admin?

I knew you would ask this :) I did go down that road, but eventually decided just to pick-and-choose selected metaboxes due to heftiness.

The taxonomy metaboxes are probably the most important for frontend purposes. The rest like excerpt, comments, thumbnail, etc. require more code and dependencies on other post functions.

For example, if we include /wp-admin/includes/meta-boxes.php, which contains all post metaboxes (including ones that do not make sense on the frontend - custom fields, revisions), we would also need to include all the other related dependencies (/wp-admin/includes/post.php, /wp-admin/includes/template.php, etc.). This includes 100s-1000s lines more code when I'm already at ~900 lines for the minimal abstraction.

The negative of my current approach is the code duplication, but I think that's a small price to pay unless you think developer convenience trumps code bloat.

We can add other metaboxes on a case-by-case basis. I'm thinking the thumbnail and author metaboxes are important enough to add on the frontend. EO uses the author metabox as the Event Organiser.

Depending on how many other metaboxes we add to the frontend, I might just include the wp-admin files.

Yes. I assume the URL will be something like /event/create. Make a note that we should check event slugs against a blacklist that includes protected terms like 'create'.

I was actually thinking about using /groups/my-group/create-event/ to avoid blacklisting event slugs unless we feel a need to keep an internal slug blacklist.

Or we could bypass EO and add our own calendar rendering functions.

This wasn't something I was really considering. Just typed it down as an option :)

Can we start spinning some of these tasks off into separate items? Today I created an issue on the github repo instead of here, without really thinking.

+1 to GitHub for opening these types of issues. Let's leave this ticket to UX feedback.

The wp-admin stuff is fine with me. I don't care that much about duplicating the code. I was mainly just curious :)

I was actually thinking about using /groups/my-group/create-event/ to avoid blacklisting event slugs unless we feel a need to keep an internal slug blacklist.

Oh, I guess that's OK. Seems a bit funny to have a separate top-level nav item for it (which is what you'll get with another `BP_Group_Extension`) but maybe you can futz with it to move the nav item underneath 'Group Events'.

+1 to GitHub for opening these types of issues. Let's leave this ticket to UX feedback.

Cool. I'll sweep through tomorrow and start assigning tasks.

Boone,
Checking in how the final push is going. The date we gave ourselves for the Community Team to start testing is May 4.

Chris and I went through yesterday and took a look at the events areas together as a first pass. Below are my notes, by area:

• The 'New Event' option gets lost as a tab. It would be ideal if it was a button on the top-right (above today/month/week) of the calendar area to differentiate it from the tab. If the tab needs to be there so that the menus work correctly, then the button could be additional. https://github.com/cuny-academic-commons/cac/commit/84b9f41b3a2d161aa3597bd572076df8bd71d253

• Change "Enter title here" to "Enter Event Title" https://github.com/cuny-academic-commons/bp-event-organiser/commit/a80949e96090595247ba1e78a3004eeeb8f80bef
• Can a title be added to the main text field that says 'Event Description'? https://github.com/cuny-academic-commons/cac/commit/92c797431c6b1d3fa08f8f2810a1c235620806ac
• The calendar pop-up reduces the need for this, but it would be great if the date was mm-dd-yyyy https://github.com/cuny-academic-commons/cac/commit/cd9ba9cf2c5bf37fc14a50eb29a3b63fbd9af2ee
• Venue: does this auto-suggest based on the events across the site, or specific to that group? If it's across the site, the list might be overwhelming and an open text field would be better. I also don't see the option to add a venue in a group I created (though Chris did have the option).
• Event tags: I also am not able to add tags here, though Chris was able to. In general, this feature seems complicated both for management and filtering. We may want to leave it out of V1 and see if it's requested by users. Disabled in https://github.com/cuny-academic-commons/cac/commit/e7a196ab10f0864699bb63bac87c3b2b1a120fa3
• Change "BuddyPress Groups" to "Groups" and the explanation text to "Enter the names of each group this event should appear in." https://github.com/cuny-academic-commons/bp-event-organiser/commit/209c3bf0e520b5a6dd48aeb2d983107101613596
• How are other groups being notified that events are being connected to them?
• Change text on 'Submit for Review' button to 'Publish Event' https://github.com/cuny-academic-commons/bp-event-organiser/commit/bbd8d44606b58e237e53d4dcb00e822cc3ebc9a6, https://github.com/cuny-academic-commons/bp-event-organiser/commit/a69047b30313596ec544719e04d0f3c74a69d223
• It would be nice if 'Save Draft' and 'Publish Event' were on the same line. In addition, 'Cancel' would be helpful if they don't want to publish or save the event as a draft.
• Is the 'Visibility' area there to make it clear if an event is public or private to the group?
• It wont allow me to attach a featured image, it says I 'don't have permission to attach images to this post' even though I'm a group admin. https://github.com/cuny-academic-commons/bp-event-organiser/commit/a69047b30313596ec544719e04d0f3c74a69d223, https://github.com/cuny-academic-commons/bp-event-organiser/commit/bbd8d44606b58e237e53d4dcb00e822cc3ebc9a6
• Chris was able to add a featured image, but it doesn't appear in the live event.

• It could be valuable for there to be a 'manage' tab here like there is for personal events. For instance, someone in the group creates an event, but puts the wrong date, and then goes on vacation. This may come with some permissions baggage, but everyone who can create a group's events should also be able to manage them.

• Filters: The icons are a great idea, but may be over-cluttering the interface (and seem to be creating a glitch in the calendar view layout with overlapping). Probably best to remove them for V1. https://github.com/cuny-academic-commons/cac/commit/5e0f3b6ecdb76ea6bdbdd9ff0c940f7545c06d80
• 'Check/uncheck all' option would be great for the filters
• The personal calendar doesn't have the "today/month/week" options https://github.com/cuny-academic-commons/bp-event-organiser/commit/72f2331a98134ef769479598a89e2d1336023630

Steve - I'll have an update in a day or two.

Sam - Thanks for the feedback. Many of these are easy fixes. A few are due to what appears to be a permissions-related bug (you are not able to do some things that Chris can do), and should all be fixable together. A couple will have to wait for the next version. I'll do a full breakdown within the next couple days.

Ray, do you think you could run down the list provided by Samantha and pick out the ones that are in your arena? The permissions ones are jumping out at me.

I've updated Sam's list above to reflect fixed items: http://redmine.gc.cuny.edu/issues/1237#note-23 Perhaps we can continue to use that list to keep track of issues. Alternatively, Github issues would be fine. (Just not in scattered Redmine comments - we'll lose track.)

Comments on the remaining items:

Venue: does this auto-suggest based on the events across the site, or specific to that group? If it's across the site, the list might be overwhelming and an open text field would be better.

I disagree. (a) Even after a large amount of use, it's likely that there won't be more than a few dozen venues. (b) The auto-suggest specifically makes it so that it's not overwhelming, by quickly narrowing down the options. (c) (most importantly) Limiting suggest to those venues created by a group means that there will be many entries for, say, the Graduate Center. This creates extra work for people creating events, and makes it so that we can't ever (say) have a feature where we show all upcoming events happening at the Graduate Center. I suggest that either we ship with what we've currently got, or we disable venue saving altogether and make people reenter the venue each time they create an event.

How are other groups being notified that events are being connected to them?

Whenever an event is edited or created, a corresponding activity item is created in each connected group. Users will receive email notifications of these changes based on their group notification preferences.

It would be nice if 'Save Draft' and 'Publish Event' were on the same line. In addition, 'Cancel' would be helpful if they don't want to publish or save the event as a draft.

The UI here is based on what WP does in the back end. Perhaps you could create a rough mockup for what you want? We've already made some tweaks here, and it'd be nice to make it how you'd like it with just one more edit.

Is the 'Visibility' area there to make it clear if an event is public or private to the group?

Again, this is ported directly from the WP backend, as well as from Event Organiser, which has support for Private events. I agree that it's not a great or obvious piece of UI, and in the long run I think we should think about abandoning the built-in interface and building our own. In the meantime, please have a look at Ray's most recent revision of the visibility interface. https://github.com/cuny-academic-commons/bp-event-organiser/issues/28#issuecomment-98883747

Chris was able to add a featured image, but it doesn't appear in the live event.

It's possible that we'll drop this feature for v1. See https://github.com/cuny-academic-commons/bp-event-organiser/issues/17#issuecomment-99083587

It could be valuable for there to be a 'manage' tab here like there is for personal events. For instance, someone in the group creates an event, but puts the wrong date, and then goes on vacation. This may come with some permissions baggage, but everyone who can create a group's events should also be able to manage them.

This is a can of worms. If I create an event and choose to link it to group X, how much ability should the admin of group X have to edit that event? Perhaps they should be able to nix the group connection, but it's not obvious to me at all that they should be able to edit the content. I strongly suggest we table discussion of a group Manage tab for the time being.

'Check/uncheck all' option would be great for the filters

I'll create a ticket for this, but I'm assuming it's not mission-critical for v1. (It's not trivial to build, because there are weird issues having to do with the way the filters refresh the events.)

Forgot to mention that all of the changes above (in addition to other improvements from the past few days) are available on cdev. After today's dev team call, I'll probably prepare a testing document for the team. Stay tuned :-D

http://gifrific.com/wp-content/uploads/2012/12/Neil-DeGrasse-Tyson-Dancing.gif