# Editing posts cause notification

**URL:** <https://meta.discourse.org/t/editing-posts-cause-notification/104873>\
**Category:** Support\
**Created:** [December 22, 2018, 12:34am UTC](https://meta.discourse.org/t/editing-posts-cause-notification/104873 "2018-12-22T00:34:51Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![Grayden\_Shand](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/grayden_shand/32/166586_2.png) [@Grayden\_Shand](https://meta.discourse.org/u/Grayden_Shand)\
**Post date:** [April 23, 2021, 1:15pm UTC](https://meta.discourse.org/t/editing-posts-cause-notification/104873/23 "2021-04-23T13:15:08Z")

</div>

> [@sam](#):
>
> If we start being fancy and only notifying new @groups on edit we will be stuck with complex code that has to walk through diffs and lots more bookkeeping.

So, imagine a post with 3 different group mentions. It’s edited and a fourth mention is added.

When saving the edit, we can use a query like this to find the current list of group mentions for that post.

```plaintext
-- [params]
-- text :post_id

select gm.group_id, g.name
from group_mentions gm
join groups g on (gm.group_id = g.id)
where post_id = :post_id

```

Then, by comparing the results of the query against the list of groups being mentioned in the post, we can find the new mention(s).

That doesn’t seem like too big of a calculation, but maybe I’m missing something obvious. This also seems like the sort of thing that could be done in a background task.

As far as the JIT banner about notifying the group(s), maybe this logic could be exposed by an API endpoint (`/post/<id>/mentions.json`) to get this data asynchronously.

---

_[View the full topic](https://meta.discourse.org/t/editing-posts-cause-notification/104873)._