Add observation filters associated with observation updates (notifications)

Feature Requests
1

Separate from the long-awaited plans for a new notifications dashboard, notifications indicator, and related functionality, I think it would be useful to add a mechanism in the web Explore and Identify screens to allow users to filter for observations that have new updates. I know that the web Explore screen has a long-awaited planned update. So I think changes there should be limited to accepting a new set of URL parameters (detailed below), avoiding GUI changes. The Identify screen ideally would get a human-friendly way to filter for observations with notifications, but if that’s too complicated, then it would be fine to just go with URL parameters there, too. (I don’t think new functionality would need to be added to the mobile app Explore screen, since the mobile app already has a good Activity screen.)

“Updates” in this proposal would be equivalent to the items returned from GET /v1/observations/updates. (These are the notifications specific to observation updates that folks can view in the Activity screen in the mobile app or via https://jumear.github.io/stirfry/iNat_observations_updates .)

Here are the sort of parameters that I think could be added to GET /v1/observations (and reflected in the web Explore and Identify screens):

parameter value
notification_user_id (numeric input for id or string input for login)
notification_for observer, follower, any (default)
notification_type identification, disagreement (subset of identification), refinement (subset of identification), comment, mention (overlaps with either identification or comment), any (default)

It’s not necessary, but it also would be nice if new identifications and comments were highlighted in the web observation detail screen (ex. https://www.inaturalist.org/observations/23990264) and observation detail modal in the Identify screen. (I think that might require adding a notification_user_id parameter to GET /v1/observations/{id} and adding basic information from /v1/observations/updates to its response.)

I’m hoping this sort of thing would be relatively easy to accomplish (compared to the existing planned notifications updates). So maybe it could be implemented before the notifications updates and provide a lot of utility sooner than later.

I also thought about maybe how this sort of filter could be applied for subscriptions, but I’m not sure if subscription notifications can be marked as viewed in the same way as observation updates are. So if that mechanism doesn’t exist for subscription notifications, then it would be hard to add similar observation filters for those.

2

How do you define “new” updates - those not yet viewed by a user, or some period of time, or …?

3

I like this idea a lot, it can be difficult to view all of my new notifications when I have over 30 at once. Being able to use the viewer on the explorer page to do this would make it more visually intuitive in my opinion

4

for the purposes of the feature request, it would be only ones not yet viewed by the user (viewed=false). this means that the user has not either (1) viewed the notification from the notification bubble thing in the top right corner of the website, nor (2) opened the observation in the observation detail page or Identify screen modal (since that triggers a thing that flags all notifications on the observation as viewed=true).

there is an existing created_after parameter for GET /v1/observations/updates that could be used as the basis for some time period filtering, but i think trying to incorporate that in the Explore and Identify screens would be overly complicated.