Before we do the advanced features at #1004554: Allow conference attendees to pre-network, make connections and in order to get closer to matching the Attend page on http://drupal.org/files/issues/cod-connect-attend.pdf from #1004698: Proposed COD information architecture, let's add a display to the attendees view that has these exposed filters.

Comments

ezra-g’s picture

Issue tags: +cod-alpha3

Let's get this into cod-alpha3.

lisarex’s picture

StatusFileSize
new17.5 KB

Attached is an exported feature. It abandons the previous View called 'attendees'. We might want to call this view something like 'community' if more of the social/community features we have planned are added to it it.

ezra-g’s picture

Status: Active » Needs work

Big +1 on changing from cod_attendees to cod_community.

We need to update the machine name used for the job title profile field, since the current one results in broken views handlers, and also add a more human-readable name for the feature.

I think we can add the location bits separately later as part of #1026386: Add html5_user_geolocation for user locations.

ezra-g’s picture

Assigned: Unassigned » ezra-g

I'm working on this locally. One thing to note: If this is the 'community' view, do we want to retain a second display for "attendees" so that folks can see who is attending? Should it have the same filters? Perhaps it should be a tab on the community display.

lisarex’s picture

I'd love to test this on folks... my answer depends on how the other social features (friending, fanning) are displayed as well. One the one hand, Community is the landing page and it features the Attendees. But does this Community page do much else other than provide filterable access to attendee lists and highlight Forum activity?

So having an Attendees view with the same filters doesn't worth it, unless the Attendee view has a different purpose ... maybe we just want to display names and faces like many other conference sites do and cut the exposed filters down to what makes sense?

In fact maybe the Community page default view is names + faces, and the extra exposed filters and table view appear on the Attendees page? Are names + faces only that useful to people?

However, right now I'm thinking that we don't need a 2nd display though.

ezra-g’s picture

Agreed, let's stick with this display for now.

Slight complication:

http://drupalcode.org/viewvc/drupal/contributions/modules/cod_support/co...

This feature depends on views that don't exist after we remove the existing cod_attendees :\. I'll add some placeholder displays to the new cod community view for now. I look forward to removing context in favor of panels as part of #1011844: Better default frontpage .

ezra-g’s picture

Status: Needs work » Needs review
StatusFileSize
new20 KB

I've added a block display with the right machine name, fixed broken handlers errors and made both displays require the signup:user relationship and updated the human readable feature name & description.

This will replace cod_attendees, which will be removed.

ezra-g’s picture

The signup.module default vbo admin view adds the "Signup: User: " relationship the user name field. I didn't notice a change in behavior leaving this relationship out as it's required on the view but we should double check before committing.

ezra-g’s picture

Title: Add display with exposed filters to cod_attendes » Cod community with attendee search view
Status: Needs review » Fixed

I tested and verified that the view functions as expected without adding the signup:user relationship to each field. It's probably important on the vbo view since that one uses both the signup:user and signup:node relationship in the same display.

I also updated the view name to just "attendees" so that it matches the cod_front_page context.

Who knew this seemingly basic feature would be such a big commit?

http://drupal.org/cvs?commit=488770

Thanks!

lisarex’s picture

Component: cod_attendees » cod_community

updating component

Status: Fixed » Closed (fixed)
Issue tags: -cod-alpha3

Automatically closed -- issue fixed for 2 weeks with no activity.