On-site notifications by pablobm · Pull Request #7030 · openstreetmap/openstreetmap-website

pablobm · 2026-04-23T16:18:16Z

Partially addresses #7018

This implements on-site notifications. The risk of scope creep is high on a feature like this, so I have kept it intentionally simple. It can be improved over time, as we learn more.

To see it in action, you can visit https://pablobm.apis.dev.openstreetmap.org/notifications (credentials: mapper//password). As of writing these lines, all types of notifications are present and it should look a bit like this:

The proposed Notifications page, showing a list of notifications: changeset comments, note comments, new followers, etc

Notifications are listed in a dedicated page so that client apps (eg: JOSM) can easily link to them.

What is not implemented:

Marking notifications as seen/read. That's its own can of design worms.
Similarly, any indication (number, red dot, etc) that there are unseen/unread notifications.
Any means to delete/hide notifications.
Hiding notifications that refer to items that have been made invisible (eg: a note was hidden). An email notification won't disappear from your inbox just because it refers to something that was removed, so it's not super important to do it here immediately.
Dealing with N+1 queries. I am not sure that it's worth it, with 20 items per page and 6 different types of content. Perhaps fragment caching would be better here, but I think this should be done separately.
Showing only an excerpt of potentially large pieces of text (eg: long diary comment). Again, several approaches are possible, so let's discuss it separately.

The design can also lend itself to a lot of discussion. I gave it a few iterations and ended up with something that I think works, even if it can be improved over time.

1ec5

Yay, I’m excited to use this even before extra polish, instead of missing e-mail notifications that get lost in my inbox!

1ec5 · 2026-04-23T17:03:36Z

+    <%= t(
+          ".notification_header_html",
+          :changeset_comment_link => link_to(
+            t(".changeset_comment"),
+            changeset_path(
+              notification.changeset,
+              :anchor => "c#{notification.comment_id}"
+            )
+          ),
+          :commenter_name_link => link_to(
+            notification.commenter.display_name,
+            notification.commenter
+          ),
+          :time_ago => friendly_date_ago(notification.timestamp)
+        ) %>


All other notification types.

As we add more notification types, would there be any opportunity to factor out some common elements to avoid boilerplate? This code to generate the header seems like a candidate for that, except that some notification types probably won’t have anything analogous to a commenter or a page to link to.

Since the intention is to communicate all the information that’s currently going out in e-mails, what if we add a consistent heading that’s based on the subject line of those e-mails? For simplicity, it could remain as plain text. Then, these details specific to changeset comments could be a separate line below it. Or maybe the code to generate a rich text heading could live alongside the existing code that generates the plain text subject line.

Sharing content with the emails, including the subject line, makes a lot of sense; I'll play a bit with the idea. Sharing code between the two might be tricky but at worst we can accept it as incidental duplication and that's fine.

As for sharing code across notifications, let's see where this goes. This line in particular looks difficult to factor out to me, as each translation line will have different names and fiddly details, but who knows.

I have reached a design that I'm liking enough for now and should cover all the bases. I have gone for different wordings from those used in email... because I don't like the email ones 😓 I think my choices are simpler and the emails could be improved.

Also the ability for reuse is a bit limited. Even for translation strings, reusing across different contexts is tricky. I'm not sure it can be done without having to write long keys in each case (eg: t(".subject") vs t("some_context.notifications.changeset_comment.subject")).

The templates do have a lot of repetition. I could go try DRY them up a bit, but at this stage it's better if we put them to the test first.

1ec5 · 2026-04-23T17:04:46Z

+
+<% @notifications.each do |notification| %>
+  <%= render :partial => notification.to_partial_path, :object => notification, :as => :notification %>
+<% end %>


This would be a good opportunity to link to the notification preferences in #7001, depending on which PR lands first.

Good point. Yes, I think users are now used to "click here to change your notification preferences" at places like this.

I have added a link to this effect at the top, in the header section (see latest screenshot).

1ec5 · 2026-04-23T17:07:30Z

+  </p>
+  <blockquote class="mx-2 fst-italic">
+    <p class="text-truncate"><%= notification.comment_body.truncate(200, :separator => " ") %></p>
+  </blockquote>


Should we add some kind of action button below or to the right of the notification, like an “Open Comment” button that does the same thing as the “Changeset Comment” link currently does? It would be a nice place to put a Mark as Read/Unread button once we have that functionality, similar to what we have in the Inbox.

Yes, it makes sense to provide a unified "take me to the source of the notification" button.

I have made it so that the headline of each type of notification links to the appropriate event (note comment, uploaded trace, etc).

github-actions · 2026-05-11T13:45:53Z

	1 Warning
⚠️	Number of updated lines of code is too large to be in one PR. Perhaps it should be separated into two or more?

Generated by 🚫 Danger

pablobm · 2026-05-13T19:47:50Z

This is ~~not~~ now ready for a proper review.

pablobm · 2026-05-13T19:49:00Z

I meant "now" in my previous comment... 😓 (Adding this new comment for the benefit of email notifications).

1ec5 · 2026-05-13T20:29:39Z

Apparently there’s some delay in the GitHub notification e-mails so that I saw your edit reflected there. This is not a feature request for OSM e-mail notifications. 😉

pablobm · 2026-05-14T17:47:20Z

Pushed a change to allow for the case when changesets don't have a summary "comment". Updated the screenshot in the description to show an example.

pablobm force-pushed the onsite-notifications branch from acdb057 to 6466916 Compare April 23, 2026 16:35

1ec5 reviewed Apr 23, 2026

View reviewed changes

pablobm force-pushed the onsite-notifications branch 3 times, most recently from c8c1287 to 58acba4 Compare May 6, 2026 09:36

pablobm force-pushed the onsite-notifications branch 3 times, most recently from 72131ba to 5eff28d Compare May 11, 2026 13:27

github-actions Bot added the big-pr label May 11, 2026

pablobm force-pushed the onsite-notifications branch 11 times, most recently from 9090cf2 to 695362a Compare May 13, 2026 11:28

pablobm marked this pull request as ready for review May 13, 2026 19:39

pablobm added 2 commits May 14, 2026 11:40

Create page to list notifications

b07402d

Skeleton to implement each type of web notification

2f14d8f

pablobm force-pushed the onsite-notifications branch 2 times, most recently from f779c0c to 00bafaa Compare May 14, 2026 17:16

Implement web notifications for changeset comments

8f85fce

pablobm added 5 commits May 14, 2026 18:19

Implement web notifications for note comments

2ea9380

Implement web notifications for diary comments

e3a46e7

Implement web notifications for new followers

88a6e1f

Implement web notifications for GPX imports completion

f4f5d91

Paginate notifications

b61168c

pablobm force-pushed the onsite-notifications branch from 00bafaa to b61168c Compare May 14, 2026 17:19

pablobm mentioned this pull request May 20, 2026

Provide an API to access user notifications #6896

Open

1ec5 mentioned this pull request Jun 2, 2026

Track whether the user has read an in-site notification #7123

Open

Conversation

pablobm commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

1ec5 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 11, 2026

Uh oh!

pablobm commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pablobm commented May 13, 2026

Uh oh!

1ec5 commented May 13, 2026

Uh oh!

pablobm commented May 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pablobm commented Apr 23, 2026 •

edited

Loading

pablobm commented May 13, 2026 •

edited

Loading