For my use case, I need a shared calendar between groups.
More specifically, and for a beginning, a user should be able to view, on the same calendar, all public events, or all events from their groups, or both.
@agorakit you have thought of reforming your code with a "Context" object. Would this be a pre-requirement in your opinion?
I guess so ..
How could I help?
For instance, in ContextService.php I would like to write getVisibleGroups() in a way it only depends on the context itself, as retrieved by ContextService::get(). (and authentication status of course).
Alternatively, we could write 2 methods:
Isn't it already the case? If a user is member of group A, B and C,when visiting the overview page, calendar tab will show events from the 3 groups. You can choose to see "my groups" or all public groups (including "my groups").
What else would you need ?
I have all this in mind:
* - group : all visible stuff in a given group
* - joined : all stuff in groups joined by the user
* - custom : all visible stuff in a custom list of groups
* - custom+: all stuff in groups joined by the user + all visible stuff in a custom list of groups
* - public : all public stuff
* - public+ : all stuff in groups joined by the user + all public stuff
* - all : (admin)
"context" would be in session. So would be the custom list of groups, if any.
An authenticated user could set context (and maybe custom list as well) as a preference.
+ any user (authenticated or not) would be able to set a context for the session.
I fear this will make for a very complex UI for end users and I'm not sure about the use case there : to have such a granular control on calendar display means you have several groups that have like more than 4 events per day, in this case yes, the calendar could become too crowded and would require advanced filtering. Does it really happen ? I never saw this on the shared instance.
Mmm..
In my use case, we will have several dozens groups that users might want to select from. Additionally, I want them to be able to download their resulting calendar as a table in a PDF file that would stay compact, ie readable within one single page with all information for "next week" or even "next month" depending of their wishes.
it is an issue, only if we don't think about reasonable defaults ..
I would advice to decide based on real data when in use, because it might be a non issue.
Maybe the option to generate a specific calendar with proper filtering would be good, I don't know.