Project

General

Profile

Bug #5717

Events not showing up on sitewide events calendar

Added by Matt Gold over 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Events
Target version:
Start date:
2016-06-20
Due date:
% Done:

0%

Estimated time:

Description

I was at a meeting recently and people said that an event that was on a group public calendar -- the digital research institute here - https://commons.gc.cuny.edu/groups/gc-events-and-workshops/events/ - wasn't showing up on the sitewide events calendar ( https://commons.gc.cuny.edu/events/ )

I see it there when I look through my admin account, but when I log in as Test Student, I do not see the event.


Related issues

Related to CUNY Academic Commons - Bug #6482: can 1.10 Events Test IssueResolved2016-10-27

Related to CUNY Academic Commons - Design/UX #4595: Event Creation - Privacy Level IndicationDuplicate2015-09-11

History

#1 Updated by Boone Gorges over 3 years ago

  • Category name set to Events
  • Target version set to 1.10

The event is associated with two groups:

- http://commons.gc.cuny.edu/groups/gc-events-and-workshops/
- http://commons.gc.cuny.edu/groups/gc-digital-fellows/

The first one is public. The second is private.

The plugin is designed in such a way that an event associated with at least one private group is also labeled as private. There's a note to this effect when you associate an event with a group: "You have added a group to this event. Since groups have their own privacy settings, we have removed the ability to set the status for this event."

On this design, the fact that the event is showing up for non-logged-in users at http://commons.gc.cuny.edu/groups/gc-events-and-workshops/events/ is a bug. Even though that group is public, the event is technically not private, and should be inaccessible for people who aren't members of the GC Digital Fellows group.

I'm aware that this privacy setup is not ideally flexible. But the problem is complex. Anyone can associate an item with a group. So if Matt creates an event for a private group, intending it to be private, it doesn't seem right that another member of the private group should be able to make the event public by associating it with a public group. The current behavior is meant to be a stopgap until we can design a more sophisticated system that makes sense.

For the purposes of this ticket:
a. We should figure out why the event is showing up on the public calendar, and fix that bug. (Should check direct access to the single event, too.)
b. To display the event on the global calendar, remove its association with the GC Digital Fellows group.

#2 Updated by Matt Gold over 3 years ago

Hi Boone,

In cases like this, I wonder whether we could differentiate between the public and private versions of the same event, and show only the public version on the global calendar. Ie, the event wouldn't show group associations with private groups, but would appear on the public calendar associated with the public group because it was shared publicly.

#3 Updated by Boone Gorges over 3 years ago

The system currently has no concept of "versions" of a single event. If there's a use case for such a concept, I think we can discuss it, but it seems confusing to me personally. What would different versions "inherit" from each other, or from a shared parent?

In any case, for the current purposes, you could just manually create a duplicate of the event. If this is what you mean, then yes, it sounds like a good idea.

#4 Updated by Matt Gold over 3 years ago

Well, let's take the case in point -- the GC Digital Research Institute. We wanted it on the public GC calendar because it's part of the global listings for the GC. But we also wanted it to be on the digital fellows calendar; I don't think that it's intuitive that sharing an entry for a public event with a private group would make the public event disappear from the global calendar.

Perhaps architecturally, when someone tries to create an event and share it across public and private calendars, we could in effect create two different calendar entries -- one public, and one private. The public entry could be shared across all public calendars as the user chooses, and the same with the private calendar. And then the public event could be shared on the global calendar.

Does that make sense?

#5 Updated by Luke Waltzer over 3 years ago

I'm not sure much of this is seeming intuitive to me, but I wasn't involved at the planning stages and am not fully aware of the dependencies of the Events Calendar. Doesn't seem right to me that any user can affiliate any event with any group's calendar. Is that functionality necessary to fuel the global calendar?

I'm also curious how many private groups are creating events at this stage; is it only the Fellows? Most use of the calendar seems to be to promote.

#6 Updated by Boone Gorges over 3 years ago

I don't think that it's intuitive that sharing an entry for a public event with a private group would make the public event disappear from the global calendar.

As noted above, we didn't build the system this way because we thought it was the best system. We needed a stopgap until we could come up with a full-fledged permission system.

Perhaps architecturally, when someone tries to create an event and share it across public and private calendars, we could in effect create two different calendar entries -- one public, and one private. The public entry could be shared across all public calendars as the user chooses, and the same with the private calendar. And then the public event could be shared on the global calendar.

I'm not really concerned with how it's implemented under the hood (though creating duplicate events has implications for how event edits are propagated, and other sync-related problems). More important is the user flow. What you're suggesting is effectively the opposite of what we're currently doing: when an event is associated with more than one group, its privacy level defaults to the level of the most open of the groups, rather than the least open. I think this is OK, but we need to have appropriate notices for the administrator, and we need to be careful that it's not possible for other group members to hijack and publicize an event against the admin's wishes.

Doesn't seem right to me that any user can affiliate any event with any group's calendar. Is that functionality necessary to fuel the global calendar?

I was partly wrong about this. This affiliation can only happen for users who can edit an event. With the exception of super admins, the only person who can edit an event is the author of the event. But there may be implications in the future, if we decide to allow event editing for, eg , group admins.

#7 Updated by Matt Gold over 3 years ago

Boone Gorges wrote:

when an event is associated with more than one group, its privacy level defaults to the level of the most open of the groups, rather than the least open. I think this is OK, but we need to have appropriate notices for the administrator, and we need to be careful that it's not possible for other group members to hijack and publicize an event against the admin's wishes.

If this is the case, then why would an event shared on one private and one public calendar not show up on the global calendar?

I'm not really concerned with how it's implemented under the hood (though creating duplicate events has implications for how event edits are propagated, and other sync-related problems). More important is the user flow

This is what I'm concerned about, too!

Doesn't seem right to me that any user can affiliate any event with any group's calendar. Is that functionality necessary to fuel the global calendar?

I was partly wrong about this. This affiliation can only happen for users who can edit an event. With the exception of super admins, the only person who can edit an event is the author of the event. But there may be implications in the future, if we decide to allow event editing for, eg , group admins.

For this particular use case, the user who created the event was a member of both the public and the private group between which the event was shared

#8 Updated by Boone Gorges over 3 years ago

If this is the case, then why would an event shared on one private and one public calendar not show up on the global calendar?

Two groups: A (public), B (private). Currently:

1a. Associate with A: Event is public
2a. Associate with B: Event is private
3a. Associate with A and B: Event is private (deferring to the least open group setting)

Your suggestion is:

1b. Associate with A: Event is public
2b. Associate with B: Event is private
3b. Associate with A and B: Event is public (deferring to the most open group setting)

Events only show up on the global calendar if they are public. QED

We went with (a) for the initial implementation. If we want to go with (b) instead, it's fine, but we will need to change the dynamic prompts to warn users about this behavior.

#9 Updated by Matt Gold over 3 years ago

Okay -- I misread your earlier message to say that current behavior defaults to most open.

In thinking this through, I'd say that we should default to most open if an event is posted to multiple privacy settings -- ie, if an event is posted to both a public and a private group, it is already public -- and therefore should be on the global calendar. Can you (or anyone cc'ed on this ticket) think of a use case where an event posted to a public and private calendar shouldn't be on the global calendar?

#10 Updated by Boone Gorges about 3 years ago

Okay -- I misread your earlier message to say that current behavior defaults to most open.

Ah, I just reread my sentence and I see that it could be read both ways. Sorry :)

Can you (or anyone cc'ed on this ticket) think of a use case where an event posted to a public and private calendar shouldn't be on the global calendar?

This is the kind of scenario I had in mind:

So if Matt creates an event for a private group, intending it to be private, it doesn't seem right that another member of the private group should be able to make the event public by associating it with a public group.

But now I'm playing with the plugin and I can't actually figure out a way to do this. It appears that events can't be edited by other group members, which means that non-authors can't do what I've suggested above. So let's go ahead and make the change.

#11 Updated by Matt Gold about 3 years ago

Okay -- thanks, Boone.

#12 Updated by Boone Gorges about 3 years ago

  • Assignee changed from Boone Gorges to Raymond Hoh

GitHub ticket: https://github.com/cuny-academic-commons/bp-event-organiser/issues/55 I'm going to reassign the Redmine ticket to Ray for the time being. Ray, if this needs to come back in my direction, please feel free. (And if this turns out to be a big lift for 1.10, it can probably be punted.)

#13 Updated by Raymond Hoh almost 3 years ago

  • Status changed from Assigned to Testing Required

This is done.

View the commit made in the bp-event-organiser repo.

cdev is also running this latest change, so please test and let me know if you encounter any issues.

#14 Updated by Boone Gorges almost 3 years ago

  • Related to Bug #6482: can 1.10 Events Test Issue added

#15 Updated by Boone Gorges almost 3 years ago

  • Status changed from Testing Required to Resolved

A bug was reported in #6482, so let's take the discussion there and call this one fixed.

#16 Updated by Raymond Hoh 7 months ago

  • Related to Design/UX #4595: Event Creation - Privacy Level Indication added

Also available in: Atom PDF