CUNY Academic Commons

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.

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.

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?

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.

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.

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

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.

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?

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.

Okay -- thanks, Boone.