Using the two spreadsheets generated last week (you can find them in Slack), generate a list of calendars that will be marked as "Trusted" after this sprint is completed and the code pushed to production.

Done

The list should at a minimum include the IDs of the calendars that need to be set as "Trusted" but could also include the calendar title for convenience. It should be provided as a CSV file to the development team so we can pull the list of owners and admins to contact.

Add a field that marks a calendar as a "Trusted Publisher". This field will be used to allow events created on this calendar that are marked for publishing on the Main Calendar to bypass the approval process.

Done

Superadmins should be able to easily mark a calendar as a "Trusted" publisher. A check mark or other visual indication should be visible within the manager area of the calendar for administrators and editors of the calendar, with either text or a tool tip denoting what the visual indication means.

Provide a UI element that will allow users to view the short description (event list item) of their event while they're creating or editing the event. This would allow for a better view of what the event will look like on the front end prior to publishing them.

Done

The user should be able to view - either through a modal or a dedicated space within the UI - a preview of the event they're in the process of creating or editing.

Depends on #158. Generate a list of email addresses to be contacted with information about the Trusted field.

Done

The list should be a CSV that can be uploaded to postmaster and should include the email addresses of the owner and admins of each calendar.

Update the CalendarUserUpdate view to use a different method to lookup users than pulling them all into the view prior to each page load.

Look into providing a custom select2 interface to replace the dropdown. This would require creating a lookup view that would also need to be behind a login - which means sending along the authentication cookie along with the AJAX request.

Description
Add registration data to our feed views (rss/json/ics/xml)

Why it's Important
So the feeds include registration information per event

Review the current logic that is used for triggering a "re-review".

Done

Document in whether the re-review logic needs to be updated and how so that only title and description changes trigger a re-review.

All users, other than the owner of a calendar, lose access to that calendar if the name of the calendar is changed. So, for example, if the calendar name is "Department Calendar" and it is changed to "Division Calendar", only the owner of "Department Calendar" would still have access to the newly renamed "Division Calendar". Original poster also noted that changing the name back to its original name, i.e. "Department Calendar", does not result in users regaining their access.

During a meeting with Lauren and others, it was decided to add FontAwesome icons next to the location titles in both the single event and listing views.

fa-map-marker will be used for physical location, and fa-laptop for virtual.

For the single event view, the icons will be added to the left of each of the location's names.

For the listing view, they'll be added inline with the text, with a pipe separating them. See below screenshot which was approved during the meeting.

All feeds (ics, rss, json, xml) are currently paginated to 25 objects. This is most obvious with particularly busy weeks, like the week this pull request was submitted. You can see the paginated feed here:

https://events.ucf.edu/this-week/feed.rss
https://events.ucf.edu/this-week/feed.rss?page=2

I don't think limiting feed items was intended behavior, since a workaround to this is just getting the current month and filtering events by date range.

In addition to this single event template, the single event templates for ics, json, rss and xml feeds will also need to be updated to utilize the new virtual location data--though that may be outside the scope of this PR.

Originally posted by @cjg89 in #57 (comment)

Add a tool tip, or something similar to the add user area in the manager screen letting admin's know that user's must have logged in at least once before they can be added to a calendar.

Steps:

1. Create a calendar
2. Create and event that has a tag
3. Change the tag name in the manager
4. Go to the tag view for the given tag slug http://[host]/tag/[tag slug]

Not listed

Description:
Add a "Contact Calendar Admins" button/form for each of the calendar pages. We've had a few requests for people trying to find out who a calendar admin is. The form could detect the correct Owner and Admins and send an email to them without exposing names or email addresses to the person requesting support.

Why it's important:
Offloads event and calendar management issues back to the calendar owner/admins.

Alternative:
List first/last name for Owner/Admins on the calendar page, but this might make names a bit more public than what calendar owners expect or want.

Additional context:
I've had several staff around campus as well as UCF IT Service Desk ask for this kind of information. Allowing an easy way for users to contact admins would make it easier for admins to be reached and could even improve the quality of the calendar and it's events. Another component of this could also be adding a "report an issue with this event" button to individual events.

When reviewing events it would save time if the status field was at the bottom of the page and could be selected after reviewing the event rather than scrolling back to the top of the page.

To be done in parallel with #144, review the current UI elements used in the Events Create and Update views and make recommendations on improvements. While wholesale layout changes are probably not possible in this sprint, they can be noted at this time for future implementation. However, if there is a need for linking out to the documentation within a description or creating a tooltip to better explain something, we could implement those kind of changes in this sprint.

Done:
Recommendation on UI changes should be documented along with the description updates in a Google Doc to be shared with developers. Once the doc is complete, comment on issue #146 and link to the doc.

• Add a spell checker or a link to encourage people to use Grammarly. I have found it very useful when reviewing events https://www.grammarly.com/
• Add a message with suggested information to include in the event description and/or require a minimum number of characters in the event description. This will prevent empty and inadequate event descriptions.
• If another event is already added at the same date and time ask the contributor if the event they are entering is the same event to prevent duplicates.

Based on the recommendations provided by #144 and #145, the field description updates should be implemented along with any UI improvements that can be done within a 4 hour development period (including review time).

Done

Field descriptions should be updated per the referenced documentation (see comment below) and, if time allows, any UI improvements recommended made.

Describe the bug
The current output from the calendar-audit command does not include the calendar's ID, which would be very useful.

Possible Fix
Add the id field to the output array and then to the fieldnames variable and it will be included.

Describe the bug
When browsing to a page with pagination enabled, if the page number provided does not have any events, the EmptyPage exception is thrown, causing a 500 error on the front end for users. These pages can currently be indexed while the pages have events (and are therefore valid) and will remain in the index, making it possible for users to reach them, even when there isn't enough events to warrant a page load.

Steps to Reproduce

1. Choose a page to test, like the main calendar page: https://events.ucf.edu
2. Attempt to load an invalid page, e.g. https://events.ucf.edu/?page=99
3. You should receive a 500 error when trying to load the page

Expected Behavior
We should not be indexing the additional pages and ensure a user friendly message is provided when the EmptyPage exception is thrown.

Possible Fix
We should ensure that only page 1 of the results is indexed by adding a noindex meta on any pages after page 1. We should also catch the EmptyPage exception, and set an error to be processed by the template. Within the template, we could direct users to either page 1 of the results, or the last page of the results.

If necessary, update the re-review logic to ensure one is triggered only when an event's title or description is updated.

Done

You should be able to update any field within an event other than the title or description and see the update immediately on the Main Calendar copy of the event. However, if the title or description is updated, a copy of that event should be created on the Main Calendar in a re-review state, and it should show up in the re-review list.

Describe the bug
The inactive variable name doesn't exist in this context. The variable name should be invalid. Also, the stats should be outside of the with open() context.

Expected Behavior
The command currently doesn't work beyond the first loop of writing the csv. It should finish and properly report stats.

Increase the size of the WYSIWYG field to be vertically larger.

Done

The description field should be close to twice as large as it currently is to provide more editing space for event creators.

Research a spellchecker that can be used with both a WYSIWYG - in the case of the description field for events - and a regular input field - in the case fields like the title field for events.

Done

Users should be prompted with a visual indication when a misspelled word is in their title or description of an event along with suggestions for correctly spelling the word.

Description
Given problem: Many UCF events are virtual now, we need a new way to handle/schedule/manage Zoom/webinar/streaming online experiences. Currently, many people are trying to put the info in the ‘location’ and using “Online” or “Virtual” as the place… or they’re adding very long url strings into the descriptions.

Possible Implementation
Create a new virtual_url field on EventInstance that will allow a specific URL for a virtual event location to be saved on the event instance. We can then add checkboxes to the front-end form that allow users to select if their event will be held at a physical location and/or a virtual location. The physical location fields will be shown if the physical location is checked, and the virtual URL field will be shown if the virtual location is checked.

Breakdown

• Create virtual_url field on EventInstance
• Add virtual_url field and checkboxes to instance_create_update.html form
• Add logic to show/hide specific location fields when physical/virtual checkboxes are checked (make sure checkboxes are checked if fields are not empty when on the edit, review event form views)
• Display event locations on front-end single event
• Look into ways to possibly display if an event has a physical and/or virtual location in the event listing (might be moved to second sprint if it requires a greater redesign)

For this initial sprint, a random, active promotion should be displayed on every events list view and event detail view. If there are no active promotions, no markup should be added. If there is more than one promotion available, a random one should be chosen and displayed. We can improve upon this logic in the future, but this should cover us to start with.

The template for the promotion should be treated the same way as an event list item in that it should have an ESI template that an ESI tag should be used when that feature is turned on for the project.

Done

Either the promotion HTML itself or the appropriate ESI markup should be present underneath the "feeds" area of the sidebar on the Event list (calendar) view or on event detail views. If there is no active promotions, nothing should be added. If there are multiple active promotions, a random promotion should be displayed.

Describe the bug
See title. Discovered this when updating the 'Womens History Month' tag to be 'Women's History Month' and then saving an event with that tag added. The apostrophe is stripped either on save or on the move to the 'Selected Tags' bucket and a new 'Womens History Month' tag is created.

Steps to Reproduce

1. In QA: Create an event and assign it the 'Women's History Month' tag
2. The tag is added to the 'Selected Tags' list without the apostrophe.
3. On save, a new 'Womens History Month' tag is created (if not already created).

Expected Behavior
Tags should be able to be saved to an event with apostrophes.

Possible Fix
I haven't looked too much into it but I'm guessing that it has something to do with the regex used in cleanSuggestionText and cleanPromotedTagList

Your environment:

• Device: MacBook Pro
• OS: Mojave
• Browser & Version: chrome v88.0

Currently the tag and category merge modals use a simple dropdown to display the list of available terms that the tag or category can be merged into. The simple select seems to be limited to the terms displayed on the screen, which is about 20 tags. We need to look into adding a select2 field or some other type of lookup field that will allow us search all of the available tags.

Relevant URL: https://events.ucf.edu/manager/tag

Steps to Reproduce

1. Load this page and login: https://events.ucf.edu/manager/tag
2. Choose a tag to merge and select "merge" from the Actions dropdown
   
3. Observe the simple select control and the limited number of options to choose from.

Update the list of pending events within the manager view to only show each event one time, as opposed to showing the same event for each instance of the event. This will likely require changing the logic used to pull the events from the database so that we're pulling a list of events and not a list of instances, along with the appropriate template changes to reflect the new set of data.

Done

The list of pending events should only include each event once, and the count badge on the "pending" tab should reflect the count of unique events, and not instances.

There's a logical error in our clean function that's causing an Internal Server Error to be thrown when users save events under certain circumstances.

To reproduce:

1. Create a new event
2. Set the start date and end date fields, but leave the time field on both fields blank.
3. Change the recurrence settings to anything other than "Never" and set the Recur until field to a valid date.
4. Save the event after entering the rest of the content correctly.

The problem is without an end time set, the end variable will be none. While the error will get set properly that causes the error message on the front end, an exception occurs before the function returns because of this line. We need to ensure that the end variable is not None before trying to access any properties on it.

Create necessary views for managing promotions within the /manager/ area of the site. Only superadmins should be able to access these views, and they should only appear in the "Admin Menu".

Done

Superadmins should be able create new promotions, see a list of all existing promotions, edit existing promotions and delete existing promotions. The views should be similar to other views that can be access in the "Admin Menu" for consistency.

Create an initial promotion to use when the code is pushed to production. This will require an image, an alt to be used with the image and the URL to be used.

Done

Provide developers with the image, alt and URL to be used for the initial promotion to be used in production.

There's some sort of style bug happening with the "reviewed" checkbox when creating or updating an existing location that causes the checkbox to be invisible/not clickable.

Description
Given problem/description: There are quite a few of the aforementioned virtual events that require advanced registration, signing up or an RSVP. Maybe a separate field for this and a callout below the event description that displays the RSVP link/blurb?

Possible Implementation
Create a new text field for users to input specific info about Registration/RSVP and figure out how/where to display this on the front-end single event listing.

Configure the spellchecker chosen in #138 and implemented for WYSIWYG fields in #139 for input fields. The primary goal is to ensure even titles are spelled correctly.

Done

Users should be prompted visually when a word is misspelled and given a list of suggested words to choose from.

Description
Moving forward with adding functionality that allows users to have a specific field for online/virtual event URLs, we'll need to clean up/remove the existing "online", "virtual" etc. locations that were created with/without zoom/online meeting URLs. We discussed cleaning this up a little while after the Virtual URL field addition has been implemented, so that events that are currently set up this way don't lose that info.

We could move this to the second Events sprint if we do want to move forward with waiting after the virtual URL field has been in prod for a while before tackling this.

events.Calendar.admins: (fields.W340) null has no effect on ManyToManyField.
events.Calendar.editors: (fields.W340) null has no effect on ManyToManyField.
events.Calendar.subscriptions: (fields.W340) null has no effect on ManyToManyField.

Description
We have a request to make the location typeahead wider so it's easier for longer location names to fit within the suggestion dropdown.

Why it's Important
It's hard to tell which location you're selecting if the names are cut off.

Possible Implementation
We will probably need to redesign the area as a whole, because widening the location input will take away space from the selectedLocation area.

Description
Ensure searches for events includes checking assigned tags.

Why it's Important
Tags should act like little keywords in addition to organizational units.

Alternatives

Possible Implementation
We should just be able to update the query to include the tag search by adding a | Q(tag__icontains=q) or something similar.

Review the field descriptions on the Event Create and Update views and recommend improvements to make it clearer what kind of content we want in each field. If necessary, revise the descriptions and document the updates in a Google Doc to be shared with developers.

Done

All fields should be documented clearing indicating which changes are to be made. The new descriptions should be concise - be aware of the amount of space available in the UI when writing them - but also clear enough to indicate the users what each field is to be used for. Once the doc is complete, comment on issue #146 and include a link to the doc.

Currently, due to how we handle tag matches in the tag insertion/lookup field for the create/update event form, you can end up in situations such as in the screenshot below. We need to ensure that similar tags with different casing do not add duplicate tags to the new tag list.

Describe the bug

Review usage of text-overflow: ellipsis and @include text-overflow in our stylesheets and make adjustments as needed to ensure that zoomed-in users have the same contents visible to them as non-zoomed users.

Steps to Reproduce

n/a

Expected Behavior

Text should never be clipped/truncated more when users zoom their browser up to 200%.

Possible Fix

Remove/fix these occurrences.

Your environment:

n/a

Additional context

https://www.w3.org/WAI/WCAG21/Understanding/resize-text

Create a model for describing a promotion. The model should include:

1. A title (for easy identification of one promotion from another)
2. An image field (this is what will actually be displayed on the front end)
3. A URL field (this is where the image will link to)
4. An alt text field (this is what will be set in the image's alt)
5. Active field (this indicates whether a promotion should be actively displayed)

Done

The model and associated migration should be created that provides the four fields above. The model should be added to the django admin for the purposes of verifying the CRUD operations of the model.

Description
Add additional calculation to the tag score that weights the additional points awarded for the number of events assigned to the tag. Currently, the value being added to the score is equal to the number of events assigned to the tag. This is going to over-inflate the score of some tags to the point where the additional 200 points awarded for being a "promoted" tag won't bump those tags to the top.

Why it's Important
We need to normalize the score awarded for number of events the tag is assigned to in order to give the magic number awarded for promotion less arbitrary. Without normalizing this value, we will have to continually update the value of the promotion score to make it meaningful in the score calculation.

Possible Implementation
We can divide the number of events a tag is assigned to by the maximum number of events any tag is assigned to. This would have the effect of clamping the value between 0 - for tags that have less than 0.5% of the maximum number of tags assigned - and 100 - for the one tag that currently has the maximum number of events assigned.

Additional context
In order to make this practical, we're going to need a way of caching the value we're dividing by (the maximum number of events assigned to any one tag). The query to pull this number is going to be inefficient enough that we're not going to want to run it every time we pull tags.

In addition, we're probably going to want some sort of temporal limit to the tags we're looking at. For example, we may want to calculate the "assigned to" score based on the number of events the tag has been assigned to in the last 3-6 months. This will also add some complexity to the query, further making it necessary to cache this value.

Update the Facebook and Twitter links on the event page to open in a new window.

Implement the spellchecker chosen from #138 for WYSIWYG fields, primarily focusing on the description field for events.

Done

Spellchecker should prompt users visually when a word is misspelled within a WYSIWYG and allow them to correct from a list of suggested words.

Update the logic for Main Calendar suggested events to bypass the review process if the calendar creating it is a "Trusted Publisher".

Done

1. Be created on the Main Calendar with a status of "Posted" upon initial creation if the calendar creating it is a "Trusted Publisher".
2. The event should be updated without its status being changed to "re-review" if the calendar it belongs to is a "Trusted Publisher".

https://events.ucf.edu/help/#create-new-event-whenwhere

Related PR: #57

Consider moving the location-emptying logic to an on-form-submit trigger instead (so that users can check and uncheck the Physical/Virtual checkboxes and not lose existing data when editing an existing event)

Originally posted by @cjg89 in #57 (comment)