Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for notices on all event pages #1185

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

Conversation

xmedr
Copy link
Collaborator

@xmedr xmedr commented Dec 5, 2024

Overview

This branch replaces the hard coded public comment instructions with wagtail-editable objects from an EventNotice model. These objects will render according to conditions that Metro can select for each notice, and those condition options came from the conditions that were present within the event_header_*_public_comment templates. There are two sets of conditions: the status of the broadcast, and its public comment setting.

I've also updated the fixtures with a set of event notices that match what metro currently has on the site.

Testing Instructions

** Note: This PR requires a database migration, the review app will not work and this will have to be tested locally.

  • Pull down this branch and run migrations
    • You may instead run an event scrape if needed, and this would run migrations
  • To have a set of EventNotices ready, load in the cms content with the load_content management command
  • Create a super user if needed and log in to the cms localhost:8001/cms
    • hannah's from the staging site is in the fixture
  • Head to Event Notices and confirm they have loaded correctly
    • Also confirm that the About Us page content is still intact
  • Make some notices for events that exist for you.
    • Confirm that they render as expected on event detail pages, conditions and all

@fgregg fgregg temporarily deployed to la-metro-cou-feat-edit--0wub1h December 5, 2024 21:49 Inactive
@@ -1,5 +1,5 @@
<section class="row">
{% if has_agenda and not event.has_passed %}
{% if has_agenda and event_notices %}
Copy link
Collaborator Author

@xmedr xmedr Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This branch is allowing for a notice to be posted even when an event has_passed (concluded). Because of this, the styling conditionals have been adjusted to allow space for notices if they exist at all.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also something to note, any notice showing up is still contingent on the event having an agenda, to mimic the way public comment instructions only displayed if they had one as well. Lmk if we want to change this!

Base automatically changed from hcg/alerts to hcg/wagtail December 11, 2024 14:30
@xmedr xmedr changed the base branch from hcg/wagtail to main December 11, 2024 18:20
@fgregg fgregg temporarily deployed to la-metro-cou-feat-edit--6itkjs December 11, 2024 18:31 Inactive
@xmedr xmedr temporarily deployed to la-metro-cou-feat-edit--6itkjs December 11, 2024 21:48 Inactive
Comment on lines +59 to +63
{% for notice in event_notices %}
{% if "upcoming" in notice.broadcast_conditions and event.is_upcoming %}
{{ notice.message|safe }}
{% elif "ongoing" in notice.broadcast_conditions and event.is_ongoing %}
{{ notice.message|safe }}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pattern makes it so that notices only ever show if the event's broadcast status matches the notifications' conditions. This is repeated across the public_comment partials

@@ -1,5 +1,5 @@
<section class="row">
{% if has_agenda and not event.has_passed %}
{% if has_agenda and event_notices %}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also something to note, any notice showing up is still contingent on the event having an agenda, to mimic the way public comment instructions only displayed if they had one as well. Lmk if we want to change this!

Comment on lines +64 to +67
class CheckboxSelectMultipleList(forms.CheckboxSelectMultiple):
def format_value(self, value):
if isinstance(value, str):
return value.split(",")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is helping to actually display our arrayfield choices in the create/edit views

Comment on lines +65 to +73
{% if USING_ECOMMENT %}
<p>
<strong>On the web:</strong>
<a href="{{ event.ecomment_url }}" target="_blank" aria-label="Go to public comment - link opens in a new tab">
<i class="fa fa-fw fa-external-link" aria-hidden="true"></i>
Go to public comment
</a>
</p>
{% endif %}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ecomment portions of the partials have been kept for now.

Comment on lines +287 to +291
# Only provide notices for this event's public comment setting
if event.accepts_live_comment:
context["event_notices"] = EventNotice.objects.filter(
comment_conditions__contains=["accepts_live_comment"]
)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deciding which notices to pass through based off of public comment status in the view to take some burden off of the template.

@xmedr xmedr temporarily deployed to la-metro-cou-feat-edit--6itkjs December 12, 2024 15:13 Inactive
@xmedr xmedr temporarily deployed to la-metro-cou-feat-edit--6itkjs December 12, 2024 15:24 Inactive
@xmedr xmedr marked this pull request as ready for review December 12, 2024 15:26
@xmedr xmedr requested a review from hancush December 12, 2024 15:27
Copy link
Collaborator

@hancush hancush left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really snazzy! Left a few questions inline. How about also adding a link to edit the event notice to the Wagtail userbar? (See the hook that adds the manage alerts link.)

Comment on lines 87 to 91
COMMENT_CONDITION_CHOICES = [
("accepts_live_comment", "Events that accept live public comments"),
("accepts_comment", "Events that accept public comments when not live"),
("accepts_no_comment", "Events that do not accept public comments at all"),
]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, I'm a little confused by the comment conditions. I think all events accept comment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay, I was basing this off of the below section in the event template. Is this is a holdover from a time when not all events accepted comment, or maybe I'm just misinterpreting the below conditions?

<!-- Details -->
{% if not event.accepts_public_comment %}
{% include 'event/_event_header_no_public_comment.html' %}
{% elif event.accepts_live_comment %}
{% include 'event/_event_header_live_public_comment.html' %}
{% else %}
{% include 'event/_event_header_no_live_public_comment.html' %}
{% endif %}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like some committee meetings don't accept comments: https://github.com/Metro-Records/la-metro-councilmatic/pull/823/files

But that's determined on the back end – this logic shouldn't be exposed in the CMS!

Copy link
Collaborator Author

@xmedr xmedr Dec 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, I've removed it from the cms!

In that case, what do you think about me bringing back the public comment instructions in the template then? Since it says different things depending on which template is being rendered, and the same "upcoming" notice would render across all those templates regardless of whether the event accepted comment or not.

Otherwise we can keep it out and leave it up to them to decide on language that would make sense for all those public comment conditions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm.................................. maybe you were right to include the comment conditions after all. Can we change the labels to:

  • Events that accept public comment before and during the meeting
  • Events that accept public comment before but not during the meeting
  • Events that do not accept public comment

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the run around!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries! It's an easy adjustment and I could've explained myself more haha.

@@ -53,78 +53,41 @@
{% endif %}
</section>

{% if has_agenda and not event.has_passed %}
{% if has_agenda and event_notices %}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering now if it would be easier to get the appropriate notice/s in the view so we can simplify the templates?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be easier once we figure out how to get those template variables to work within these notices. As of now, the conditionals that are left within these three comment templates have event specific variables in them that we wouldn't currently be able to render in the editable notice. Unless you had something else in mind!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, ok. Let's put a pin in this.

@@ -109,7 +109,7 @@
<ul class="nav col-md-6 justify-content-around justify-content-md-end list-unstyled">
<li class="ms-3"><a href="{% url 'lametro:contact' %}">Contact Us</a></li>
<li class="ms-3"><a href="{% slugurl 'about' %}">About Us</a></li>
<li class="ms-3"><a href="{% url 'metro_login' %}">Metro Login</a></li>
<li class="ms-3"><a href="{% url 'wagtailadmin_home' %}">Metro Login</a></li>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@hancush hancush temporarily deployed to la-metro-cou-feat-edit--6itkjs December 12, 2024 20:28 Inactive
@hancush
Copy link
Collaborator

hancush commented Dec 12, 2024

P.s., I pushed an updated fixture omitting the OCD models – it should only contain content managed by the CMS!

@xmedr xmedr temporarily deployed to la-metro-cou-feat-edit--6itkjs December 17, 2024 16:58 Inactive
@xmedr
Copy link
Collaborator Author

xmedr commented Dec 18, 2024

@hancush public comment changes reverted and notices added to userbar!
image

@hancush
Copy link
Collaborator

hancush commented Dec 20, 2024

I want to look at this with fresh eyes in January, but for now, it looks great, @xmedr!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create pattern for editing content that appears across a set of detail pages
3 participants