Commit Graph

168 Commits

Author SHA1 Message Date
Angus McLeod
cb4b8146a3
Add dedicated user_api_key_clients table to allow for 1:many use cases () 2024-11-08 12:05:03 -05:00
Martin Brennan
e9b427ff53
FEATURE: Change default for push_notification_time_window_mins ()
Currently the push_notification_time_window_mins is set to 10
minutes by default. We want to change this to 1 minute, which is the
delay it has been set to on meta and our internal site already for over
a year now.

This conforms to the expectation users have that notifications are
delivered close to immediately.
2024-08-20 15:46:07 +10:00
David Battersby
0954ae70a6
FEATURE: add delay to native push notifications ()
This change ensures native push notifications respect the site setting for push_notification_time_window_mins. Previously only web push notifications would account for the delay, now we can bring more consistency between Discourse in browser vs Hub, by applying the same delay strategy to both forms of push notifications.
2024-08-13 12:12:05 +04:00
Martin Brennan
48d13cb231
UX: Use a dropdown for SSL mode for group SMTP ()
Our old group SMTP SSL option was a checkbox,
but this was not ideal because there are actually
3 different ways SSL can be used when sending
SMTP:

* None
* SSL/TLS
* STARTTLS

We got around this before with specific overrides
for Gmail, but it's not flexible enough and now people
want to use other providers. It's best to be clear,
though it is a technical detail. We provide a way
to test the SMTP settings before saving them so there
should be little chance of messing this up.

This commit also converts GroupEmailSettings to a glimmer
component.
2024-07-18 10:33:14 +10:00
Natalie Tay
0b41b236d7
FIX: Avoid sending user emails if @ mentioning a staged user in a topic ()
Avoid sending user emails if @ mentioning a staged user

Some cases, unknowingly mentioning a staged user would invite
them into topics, sending them an email about it.
2024-03-13 11:05:34 +08:00
Mark VanLandingham
6c2c690479
DEV: Add push notification filtering to MessageBus alerts () 2024-02-29 12:49:46 -06:00
Mark VanLandingham
b426f85a81
DEV: Add modifiers for plugins to customize push notification translation arguments () 2024-02-27 14:03:55 -06:00
Ted Johansson
7e5d2a95ee
DEV: Convert min_trust_level_to_tag_topics to groups ()
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_to_tag_topics site setting to tag_topic_allowed_groups.
2024-01-26 13:25:03 +08:00
Ted Johansson
57ea56ee05
DEV: Remove full group refreshes from tests ()
We have all these calls to Group.refresh_automatic_groups! littered throughout the tests. Including tests that are seemingly unrelated to groups. This is because automatic group memberships aren't fabricated when making a vanilla user. There are two places where you'd want to use this:

You have fabricated a user that needs a certain trust level (which is now based on group membership.)
You need the system user to have a certain trust level.
In the first case, we can pass refresh_auto_groups: true to the fabricator instead. This is a more lightweight operation that only considers a single user, instead of all users in all groups.

The second case is no longer a thing after .
2024-01-25 14:28:26 +08:00
Penar Musaraj
f2cf5434f3
Revert "DEV: Convert min_trust_level_to_tag_topics to groups ()" ()
This reverts commit c7e3d27624 due to
test failures. This is temporary.
2024-01-15 11:33:47 -05:00
Ted Johansson
c7e3d27624
DEV: Convert min_trust_level_to_tag_topics to groups ()
We're changing the implementation of trust levels to use groups. Part of this is to have site settings that reference trust levels use groups instead. It converts the min_trust_level_to_tag_topics site setting to tag_topic_allowed_groups.
2024-01-15 20:59:08 +08:00
Krzysztof Kotlarek
702d0620d7
DEV: Convert min_trust_to_create_topic to groups ()
This change converts the min_trust_to_create_topic site setting to
create_topic_allowed_groups.

See: https://meta.discourse.org/t/283408

- Hides the old setting
- Adds the new site setting
- Add a deprecation warning
- Updates to use the new setting
- Adds a migration to fill in the new setting if the old setting was
changed
- Adds an entry to the site_setting.keywords section
- Updates tests to account for the new change
- After a couple of months, we will remove the min_trust_to_create_topicsetting entirely.

Internal ref: /t/117248
2023-12-13 14:50:13 +11:00
Daniel Waterworth
6e161d3e75
DEV: Allow fab! without block ()
The most common thing that we do with fab! is:

    fab!(:thing) { Fabricate(:thing) }

This commit adds a shorthand for this which is just simply:

    fab!(:thing)

i.e. If you omit the block, then, by default, you'll get a `Fabricate`d object using the fabricator of the same name.
2023-11-09 16:47:59 -06:00
Mark VanLandingham
88874389d2
FIX: Send push notifications for category/tag watching notifications ()
Problem and solution are outlined here on Meta - https://meta.discourse.org/t/watching-a-category-does-not-cause-push-notifications/282794
2023-11-01 10:06:33 -05:00
Martin Brennan
09223e5ae7
DEV: Remove enable_experimental_hashtag_autocomplete logic ()
This commit removes any logic in the app and in specs around
enable_experimental_hashtag_autocomplete and deletes some
old category hashtag code that is no longer necessary.

It also adds a `slug_ref` category instance method, which
will generate a reference like `parent:child` for a category,
with an optional depth, which hashtags use. Also refactors
PostRevisor which was using CategoryHashtagDataSource directly
which is a no-no.

Deletes the old hashtag markdown rule as well.
2023-08-08 11:18:55 +10:00
Sérgio Saquetim
03690ccccf
DEV: Add :push_notification event and deprecate :post_notification_alert ()
This commit introduces the :push_notification event and deprecates :post_notification_alert.

The old :post_notification_alert event was not triggered when pushing chat notifications and did not respect when the user was in "do not disturb" mode.

The new event fixes these issues.
2023-08-02 18:44:19 -03:00
Krzysztof Kotlarek
0744d242c6
FIX: post alerter notification when topic directly watched ()
In previous PR https://github.com/discourse/discourse/pull/22340 bug was introduced. Notifications were blocked when, even if topic was watched directly. New query is taking TopicUser into consideration.

In addition, in user interface, when `watched_precedence_over_muted` is not set, then value from SiteSetting should be displayed.
2023-07-06 11:27:23 +10:00
Krzysztof Kotlarek
134dcdd63a
FEATURE: allow user to override watched_precedence_over_muted setting ()
Recently, site setting watched_precedence_over_muted was introduced - https://github.com/discourse/discourse/pull/22252

In this PR, we are allowing users to override it. The option is only displayed when the user has watched categories and muted tags, or vice versa.
2023-07-04 15:08:29 +10:00
Krzysztof Kotlarek
9cf981f1f1
FEATURE: new watched_precedence_over_muted setting ()
New setting which allow admin to define behavior when topic is in watched category and muted topic and vice versa.

If watched_precedence_over_muted setting is true, that topic is still visible in list of topics and notification is created.

If watched_precedence_over_muted setting is false, that topic is not still visible in list of topics and notification is skipped as well.
2023-06-27 14:49:34 +10:00
Mark VanLandingham
114a9a10b7
DEV: Add spec for notification data modifier () 2023-06-21 08:57:25 -05:00
Selase Krakani
c45eb8a618
FIX: Create new PM notifications for watching_first_post groups ()
At the moment, PMs to groups with default notification level set to
`watching_first_post` do not generate "emailable" notifications. This happens
because, topic user notification level which is indirectly derived
from the group's default notification level is set to `tracking` if the
group's notification level happens to be `watching_first_post`.

This leads to a `group_message_summary` notification being created
instead of a `private_message` notification which results in no email
alerts being sent when a  topic is created.

As this `watching_first_post` --> `tracking` switcheroo appears to be
intentional instead being a bug, this change extends `PostAlerter`'s
`notify_pm_users` method to create a `private_message` notification for
first posts created in a `watching_first_post` group even if the topic
user notification level is set to `tracking`
2023-06-08 17:41:44 +00:00
Rafael dos Santos Silva
2a7bdb2d66
FIX: Push notification delay should not be longer than specified ()
When user.last_seen was less than push_notification_time_window_mins we
where delaying the notification for the whole
push_notification_time_window_mins PLUS the time the user was away from.

Originally reported in https://meta.discourse.org/t/-/259688
2023-03-28 13:22:54 -03:00
Sam
e636abeb0d
FIX: do not notify admins on suppressed categories ()
* FIX: do not notify admins on suppressed categories

Avoid notifying admins on categories where they are not explicitly members
in cases where SiteSetting.suppress_secured_categories_from_admin is
enabled.

This helps keep notification stream clean and avoids admins mistakenly
being invited to discussions that should be suppressed
2023-02-14 16:45:06 +11:00
Ted Johansson
25a226279a
DEV: Replace #pluck_first freedom patch with AR #pick in core ()
The #pluck_first freedom patch, first introduced by @danielwaterworth has served us well, and is used widely throughout both core and plugins. It seems to have been a common enough use case that Rails 6 introduced it's own method #pick with the exact same implementation. This allows us to retire the freedom patch and switch over to the built-in ActiveRecord method.

There is no replacement for #pluck_first!, but a quick search shows we are using this in a very limited capacity, and in some cases incorrectly (by assuming a nil return rather than an exception), which can quite easily be replaced with #pick plus some extra handling.
2023-02-13 12:39:45 +08:00
Martin Brennan
63fdb6dd65
FIX: Do not add empty use/svg tags in ExcerptParser ()
There was an issue where if hashtag-cooked HTML was sent
to the ExcerptParser without the keep_svg option, we would
end up with empty </use> and </svg> tags on the parts of the
excerpt where the hashtag was, in this case when a post
push notification was sent.

Fixed this, and also added a way to only display a plaintext
version of the hashtag for cases like this via PrettyText#excerpt.
2023-01-24 14:40:24 +10:00
Ted Johansson
421fbfd1c7
FIX: Fix flaky test resulting from PostAlerter keyword arguments ()
We've been doing some work to support new keyword argument semantics in Ruby 3. As part of that we made some changes to `DiscourseEvent::TestHelper`. The backwards compatibility fix doesn't work if the method is called with an empty hash as the final argument. This fix adds a valid option to the final hash in the particular test.
2023-01-12 09:46:50 +08:00
David Taylor
cb932d6ee1
DEV: Apply syntax_tree formatting to spec/* 2023-01-09 11:49:28 +00:00
Selase Krakani
7ba115769a
DEV: Skip push notifications for active online users ()
* DEV: Skip push notifications for active online users

Currently, users with active push subscriptions get push notifications
regardless of their "presence" on the site.

This change introduces a `push_notification_time_window_mins`
site setting which is used in conjunction with a user's `last_seen_at` to
determine if push notifications should be sent. A user is considered to
be actively online if their `last_seen_at` is within `push_notification_time_window_mins`
minutes. `push_notification_time_window_mins` is set to 10 by default.

* DEV: Remove client param for push_notification_time_window_mins site setting

Co-authored-by: Bianca Nenciu <nbianca@users.noreply.github.com>

Co-authored-by: Bianca Nenciu <nbianca@users.noreply.github.com>
2022-12-19 20:17:40 +00:00
Krzysztof Kotlarek
aa3a9b6fea
FEATURE: Differentiate notification type for directly vs indirectly watched topic ()
When user is watching category or tag (watching or watching first post) notifications are moved to other tab.

To achieve that and distinguish between post create to directly watched topics and indirectly watched topics, new notification type called `watching_category_or_tag` was introduced.
2022-12-14 10:22:26 +11:00
Krzysztof Kotlarek
f449113c8b
FIX: new pm notification should take precedence over mention ()
When a new private message is created with mention inside, notification about private message should take precedence over mention notification.

https://meta.discourse.org/t/notification-badge-for-pm-mentioning-you/232950
2022-12-09 12:23:11 +11:00
Osama Sayegh
fa9e708cb7
FIX: Don't notify topic author about small action posts () 2022-10-31 06:26:20 +08:00
Osama Sayegh
43ef44127c
UX: Send notification of type replied to topic author if they're watching the topic ()
Related to aeee7ed.

Before the change in aeee7ed, notifications for direct replies to your posts and notifications for replies in watched topics looked the same in the notifications menu -- they both used the arrow icon.

We decided in aeee7ed to distinguish them by changing "watched topics" notifications to use the bell icon because it was confusing for users who watch topics to see the same icon for direct replies and "watched topics". However, that change also means that non-power/new users who receive replies to topics _they create_ will get notifications with the bell icon because technically they're watching the topic, but the arrow icon is more appropriate for this case because we use it throughout the app to indicate "replies".

This commit adds a special-case so that if a user is watching a topic AND the topic is created by them, they receive notifications with the arrow icon (type `replied`) instead of the bell icon (type `posted`) for new posts in the topic.

Internal topic: t/79051.
2022-10-25 11:53:35 +03:00
Loïc Guitaut
26fe047724 DEV: Use AR enums in reviewables related code
This is the first patch of many to replace our custom enums in Ruby by
the ones provided by `ActiveRecord`.
2022-09-22 14:44:27 +02:00
Bianca Nenciu
0f70eae7b0
FIX: Create single notification per post and user ()
A user could receive more than a notification for the same post if they
watched both the categories and tags at different levels. This commit
makes sure that only the watching notification is created.

* Add DiscourseEvent before post notifications are created
2022-09-01 16:07:18 +03:00
Bianca Nenciu
6564d04e0d
FIX: Do not notify admins watching PM tags ()
Admins received notifications if a PM was tagged with a tag they
watched even if they were not invited to the PM.
2022-08-29 16:11:11 +03:00
Loïc Guitaut
3eaac56797 DEV: Use proper wording for contexts in specs 2022-08-04 11:05:02 +02:00
Phil Pirozhkov
493d437e79
Add RSpec 4 compatibility ()
* Remove outdated option

04078317ba

* Use the non-globally exposed RSpec syntax

https://github.com/rspec/rspec-core/pull/2803

* Use the non-globally exposed RSpec syntax, cont

https://github.com/rspec/rspec-core/pull/2803

* Comply to strict predicate matchers

See:
 - https://github.com/rspec/rspec-expectations/pull/1195
 - https://github.com/rspec/rspec-expectations/pull/1196
 - https://github.com/rspec/rspec-expectations/pull/1277
2022-07-28 10:27:38 +08:00
Loïc Guitaut
91b6b5eee7 DEV: Don’t use change { … }.by(0) in specs 2022-07-26 10:34:15 +02:00
Isaac Janzen
6ae761604a
FIX: Send quote notifications to correct users when prioritizing full names () 2022-06-09 11:52:28 -05:00
Isaac Janzen
1a12e4cfc8
FEATURE: Introduce site setting to allow for non staff pm tagging ()
Currently the only way to allow tagging on pms is to use the `allow_staff_to_tag_pms` site setting.  We are removing that site setting and replacing it with `pm_tags_allowed_for_groups` which will allow for non staff tagging. It will be group based permissions instead of requiring the user to be staff.

If the existing value of `allow_staff_to_tag_pms` is `true` then we include the `staff` groups as a default for `pm_tags_allowed_for_groups`.
2022-05-10 10:02:28 -05:00
Sam
1598e6b489
FIX: users watching tags in open tag groups not notified ()
All users are members of the EVERYONE group, but this group is special and
is omitted from the group_users table. When checking permission we need to
make sure we also add a bypass.

This also fixes a very buggy test in post_alerter, it was confirming the
broken behavior due to fabricator flow.

When it defined the tag group the everyone group automatically had full access
then the additional permission fabricated just added one more group. After
fix was made to code the test started failing. Fabricators can be risky.
2022-04-06 11:43:57 +10:00
Martin Brennan
b982992ef7
FIX: Auto-generated emails causing group SMTP email storm ()
When emailing a group inbox and including other support-type
emails (or even just regular ones with autoresponders) in the
CC field, each automated reply to the group inbox triggered
more emails to be sent out to all CC addresses to notify them
of the new reply, which in turn caused more automated emails
to be sent to the group inbox.

This commit fixes the issue by preventing any emails being sent
by the PostAlerter when the new post has an incoming email record
which is_auto_generated, which we detect in Email::Receiver.
2022-04-05 13:18:49 +10:00
Penar Musaraj
94750c81fa
FIX: Update group inbox notifications on archive/unarchive () 2022-03-11 11:57:47 +01:00
David Taylor
c9dab6fd08
DEV: Automatically require 'rails_helper' in all specs ()
It's very easy to forget to add `require 'rails_helper'` at the top of every core/plugin spec file, and omissions can cause some very confusing/sporadic errors.

By setting this flag in `.rspec`, we can remove the need for `require 'rails_helper'` entirely.
2022-03-01 17:50:50 +00:00
Jarek Radosz
2fc70c5572
DEV: Correctly tag heredocs ()
This allows text editors to use correct syntax coloring for the heredoc sections.

Heredoc tag names we use:

languages: SQL, JS, RUBY, LUA, HTML, CSS, SCSS, SH, HBS, XML, YAML/YML, MF, ICS
other: MD, TEXT/TXT, RAW, EMAIL
2022-02-28 20:50:55 +01:00
Blake Erickson
12f041de5d
FIX: Tag watching for everyone tag groups ()
* FIX: Tag watching for everyone tag groups

Tags in tag groups that have permissions set to everyone were not able
to be saved correctly. A user on their preferences page would mark the
tags that they wanted to save, but the watched_tags in the response
would be empty. This did not apply to admins, just regular users. Even
though the watched tags were being saved in the db, the user serializer
response was filtering them out. When a user refreshed their preferences
pages it would show zero watched tags.

This appears to be a regression introduced by:

0f598ca51e

The issue that needed to be fixed is that we don't track the "everyone"
group (which has an id of 0) in the group_users table. This is because
everyone has access to it, so why fill a row for every single user, that
would be a lot. The fix was to update the query to include tag groups
that had permissions set to the "everyone" group (group_id 0).

I also added another check to the existing spec for updating
watched tags for tags that aren't in a tag group so that it checks the
response body. I then added a new spec which updates watched tags for
tags in a tag group which has permissions set to everyone.

* Resolve failing tests

Improve SQL query syntax for including the "everyone" group with the id
of 0.

This commit also fixes a few failing tests that were introduced. It
turns out that the Fabrication of the Tag Group Permissions was faulty.
What happens when creating the tag groups without any permissions is
that it sets the permission to "everyone". If we then follow up with
fabricating a tag group permission on the tag group instead of having a
single permission it will have 2 (everyone + the group specified)! We
don't want this. To fix it I removed the fabrication of tag group
permissions and just set the permissions directly when creating the tag
group.

* Use response.parsed_body instead of JSON.parse
2022-01-18 15:02:29 -07:00
Roman Rizzi
e005e3f153
DEV: Create post actions without creating a notification and store custom data. ()
I plan to use this in an upcoming discourse-reactions PR, where I want to like a post without notifying the user, so I can instead create a reaction notification.

Additionally, we decouple the a11y attributes from the icon itself, which will let us extend the widget's icon without losing them.
2021-12-27 11:25:37 -03:00
Daniel Waterworth
102fa71ef3
PERF: Speed up the tests by pre-fabricating more things () 2021-12-15 11:41:14 -06:00
Roman Rizzi
0719531bd3
FIX: Notify group members when someone quotes or replies to their post. ()
When a member set a group PM notification level to Normal, we didn't notify group members if someone quoted or replied to one of their posts.
2021-12-15 09:07:39 -03:00
Roman Rizzi
b7b61d4b56
FEATURE: A notification consolidation plan for keeping the latest one. ()
We previously used ConsolidateNotifications with a threshold of 1 to re-use an existing notification and bump it to the top instead of creating a new one. It produces some jumpiness in the user notification list, and it relies on updating the `created_at` attribute, which is a bit hacky.

As a better alternative, we're introducing a new plan that deletes all the previous versions of the notification, then creates a new one.
2021-12-10 10:32:15 -03:00