Closed (fixed)
Project:
Drupal Commons
Component:
Events
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Sep 2012 at 02:03 UTC
Updated:
13 Dec 2012 at 16:10 UTC
Jump to comment: Most recent file
Right now, the "All" browsing tab will include all content belonging to the current group, regardless of whether it appears in the other tabs. Is this the expected behavior?
To fix - there is no current way to lookup the types used in the other tabs. This specifically seems unnecessary because other tabs may eventually not include strictly content types (or ill-fitting types like subgroups). I'm not sure the proper course here, but the current behavior can be confusing.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | commons skitch.jpg | 1.09 MB | Noyz |
Comments
Comment #1
ezra-g commentedGreat point.
In general I would expect that the "all" tab would, true to its label, show show literally all content in the group regardless of whether it has a dedicated tab. For example, it would include events.
I'll highlight this issue for @lisarex and @jeffnoyes in case they want to provide input (and anyone else is certainly encouraged to weigh in with perspective on this).
Comment #2
erikwebb commentedOne example for thought - if Events are featured in the browsing widget and separately in the sidebar, there is redundant content on the page.
Comment #3
erikwebb commentedComment #4
Noyz commentedTo date, we've treated events differently than every other content type. Events--while originating in a group--are different enough to A) be included as a top level accessible item (a peer to Groups) B) be capable of being created from outside of a group (see attachment). Given this to be true, I *believe* they will be perceived to be different too. As such, they way it's designed so far is..
1. "all" does not include events. The area of the group that includes filters (all, documents, posts) is a 'content' stream. We've painted the picture that Events are different, by:
A) placing them in the top level nav as a parallel to groups (even though under the covers they are just content types just like all others)
B) providing a landing page of all events (just like a landing page of all groups)
2. "events" in a group show in a sidebar for that group
Comment #5
ezra-g commentedRe-titling with the action item here.
Comment #6
ezra-g commentedMoving this to the main Drupal Commons issue queue per #1812492: Consider using central issue queue for Commons projects. Using the "Events" component since this likely wants to be an alteration to the "All" view done by Commons Events.
Comment #7
ezra-g commentedhttp://drupalcode.org/project/commons_events.git/commit/f6eff0e