Fix date formatting on the event issue template

[GBKS]

The template has been wrong, leading to events not being included in the calendar. Encountered this with three different people who created events in the past 1-2 weeks. Was wondering why I saw the issues but nothing pop up in my calendar tools. Turns out it was due to this template being wrong.

[GBKS]

@sbddesign thanks for the extra analysis. I actually did not look at the code for this update, I only did several actual tests. A other people (Mo, Bosch, and Jarol) had created call issues that did not show in the calendar (they were not included in the .ical file at all). I looked at the dates and compared them to call issues that did show up in the calendar, and noticed the difference. I tested whether adjusting the month/date order fixed the problem, and it did.

IIRC, the top two fields were meant to be a human-readable version of the event date and time. But I think we can safely remove them since we always include an everytimezone.com link.

Now that I think about it, it may have been an issue with the call label being added separately. The calendar script only runs when an issue is opened or edited. Assigning a label might not trigger it then....?

[sbddesign]

Now that I think about it, it may have been an issue with the call label being added separately. The calendar script only runs when an issue is opened or edited. Assigning a label might not trigger it then....?

I think that's likely to be the case. When I create an issue, I label it while creating it. Others may label after the fact. Then those events wouldn't make it into the calendar until somebody else edits or creates an issue, thus triggering the workflow.

I tested whether adjusting the month/date order fixed the problem, and it did.

And so this falls in line with the labeling thing. It's not the fact that you changed the date format, it's the fact that you edited the issue in some form that caused the workflow to re-trigger. If you had opened the issue and put in a cat picture instead of changing the date, probably would have gotten same result.

So here's what I suggest:

• To fix the problem of events not appearing on calendars:
  • Update the calendar issue workflow to included - labeled on line 7.
    • No guarantees, but more likely to fix the problem.
• To improve general usability:
  • Remove Date, Time, and Timezone fields.
    • These are decorative. IMHO, they don't provide value, unless you happen to live in the timezone that the call is in.
    • They confuse people because people sometimes edit one and forget to edit the other.
  • Encourage usage of UTCTime and the EveryTimeZone link.

[GBKS]

I am not sure if everyone has rights to label issues... the other tweaks sound good.

[Bosch-0]

Encourage usage of UTCTime and the EveryTimeZone link.

Yeah this is all that is needed IMO, everything else

[GBKS]

The downside of automatically applying labels to issues is that people can use them to spam the calendar. If only admins can label stuff, there is a human review element.

[sbddesign]

The downside of automatically applying labels to issues is that people can use them to spam the calendar. If only admins can label stuff, there is a human review element.

I'm not sure what you mean by automatically labeling issues. That's not what I am proposing at all. Let me try to explain in different words.

The core problem right now is that the workflow is only triggered when an issue is created or edited. This means that when a person with write access to the repo goes in and applies a label to the issue, the workflow will not get triggered until the next time somebody creates or edits an issue.

What I am proposing is that you add labeled to this list of workflow triggers. You can see a complete list of issue related workflow triggers here.

So when you add labeled to line 7, we'll end up with the following situation:

• Somebody who lacks write access to the repo opens an issue for a call
• Somebody who does have write access (e.g. @GBKS) sees the issue, and applies the Call label
• Calendar workflow is immediately triggered upon applying the label

Is that in-line with your security expectations?

[GBKS]

I added the labeled trigger, that makes a ton of sense.

As is, this PR removes the Date, Time, and Timezone fields, leaving only UTCTime and Duration, as those are actually used in the workflow code.

That code is actually a bit messy and should be cleaned up. It references some of the fields to create an Event object that is not even used.

I'd appreciate another review. Thanks in advance.