Commit Graph

314 Commits

Author SHA1 Message Date
Emmett Ling 978d52841a
FEATURE: Implement SiteSetting to Allow Anonymous Likes (#22131)
Allow anonymous users (logged-in, but set to anonymous posting) to like posts

---------

Co-authored-by: Emmett Ling <eling@zendesk.com>
Co-authored-by: Nat <natalie.tay@discourse.org>
2023-07-21 21:21:07 +08:00
Guhyoun Nam b70bd4366b
FEATURE: Separated 'trusted users can edit others' setting for trust level 3 & 4 (#21493) 2023-07-07 10:48:14 -05:00
Natalie Tay 3fe06bba9d
FIX: Allow half-merged user to be accessed in admin UI (#22105) 2023-06-14 19:19:12 +08:00
锦心 96a2893284
FEATURE: Allow expanding hidden posts for groups in SiteSetting.can_see_hidden_post (#21853)
Allow expanding hidden posts for groups in SiteSetting.can_see_hidden_post
2023-06-01 11:32:05 +08:00
Krzysztof Kotlarek 2af897df61
DEV: specs to ensure that only admin can edit Community section (#21666)
In addition, add lock that even admin can not delete Community section
2023-05-23 10:54:55 +10:00
Krzysztof Kotlarek 7ead8de232
DEV: endpoint to reset community community-section (#21664)
In upcoming PRs, admins will be able to edit the Community section. We need an endpoint which allows resetting it to the default state.
2023-05-23 09:53:32 +10:00
Jan Cernik cbbaeb55b5
FIX: Don't autojoin users when they have ready-only permissions (#20213)
After this change, in order to join a chat channel, a user needs to be in a group with at least “Reply” permission for the category. If the user only has “See” permission, they are able to preview the channel, but not join it or send messages. The auto-join function also follows this new restriction.

---------

Co-authored-by: Martin Brennan <martin@discourse.org>
2023-05-10 08:45:13 -03:00
Ted Johansson 02625d1edd
DEV: Only allow expanding hidden posts for author and staff (#21052) 2023-04-25 13:37:29 +08:00
Bianca Nenciu fb3c610f09
PERF: Optimize topic query for many categories (#20743)
Sites with many categories and many of them in muted by default (see
`default_categories_muted`) reported bad performance when requesting
the homepage as an anonymous user. This was the case because of the
long query that iterated over topics and categories trying to remove
those from the muted categories.
2023-03-22 23:31:33 +02:00
Bianca Nenciu f12e77d500
FIX: Do not allow anonymous users to be anonymized (#20776) 2023-03-22 20:51:42 +02:00
Ted Johansson b50b63808c
DEV: Make Guardian#can_see? default to false for unwatched objects (#20412)
When invoking e.g. `can_see?(Foo.new)`, the guardian checks if there's a method `#can_see_foo?` defined and if so uses that to determine whether the user can see it or not.

When such a method is not defined, the guardian currently returns `true`, but it is probably a better call (pun intended) to make it "safe by default" and return `false` instead. I.e. if you can't explicitly see it, you can't see it at all.

This change makes the change to `Guardian#can_see?` to fall back to `false` if no visibility check method is defined.

For `#can_see_user?` and `#can_see_tag?` we don't have any particular logic that prevents viewing. We previously relied on the implicit `true` value, but since that's now change to `false`, I have explicitly implemented these two methods in `UserGuardian` and `TagGuardian` modules. If in the future we want to add some logic for it, this would be the place.

To be clear, **the behaviour remains the same**, but the `true` value is now explicit rather than implicit.
2023-02-24 15:57:01 +08:00
Krzysztof Kotlarek b9d037770c
DEV: configurable public sidebar sections (#20303)
Extension of https://github.com/discourse/discourse/pull/20057

Admin can create a public session visible to everyone. An additional checkbox is displayed for staff members.
2023-02-22 08:55:44 +11:00
Loïc Guitaut f7c57fbc19 DEV: Enable `unless` cops
We discussed the use of `unless` internally and decided to enforce
available rules from rubocop to restrict its most problematic uses.
2023-02-21 10:30:48 +01:00
Sam e636abeb0d
FIX: do not notify admins on suppressed categories (#20238)
* 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
Krzysztof Kotlarek 010370f8b1
FIX: error anonymous when tl4_delete_posts_and_topics setting (#20257)
Bug introduced in this PR: https://github.com/discourse/discourse/pull/19946

When the setting is enabled, an error is triggered for anonymous users.
2023-02-13 15:34:04 +11:00
Krzysztof Kotlarek 84a87a703c
DEV: configurable custom sidebar sections (#20057)
Allows users to configure their own custom sidebar sections with links withing Discourse instance. Links can be passed as relative path, for example "/tags" or full URL.

Only path is saved in DB, so when Discourse domain is changed, links will be still valid.

Feature is hidden behind SiteSetting.enable_custom_sidebar_sections. This hidden setting determines the group which members have access to this new feature.
2023-02-03 14:44:40 +11:00
Krzysztof Kotlarek ae20ce8654
FIX: TL4 user can see deleted topics (#19946)
New feature that TL4 users can delete/recover topics and post was introduced https://github.com/discourse/discourse/pull/19766

One guardian was missed to ensure that can see deleted topics
2023-01-23 12:02:47 +11:00
Daniel Waterworth 666536cbd1
DEV: Prefer \A and \z over ^ and $ in regexes (#19936) 2023-01-20 12:52:49 -06:00
Krzysztof Kotlarek 019ec74076
FEATURE: setting which allows TL4 users to deleted posts (#19766)
New setting which allows TL4 users to delete/view/recover posts and topics
2023-01-20 13:31:51 +11:00
Isaac Janzen 292d3677e9
FEATURE: Allow admins to permanently delete revisions (#19913)
# Context
This PR introduces the ability to permanently delete revisions from a post while maintaining the changes implemented by the revisions.
Additional Context: /t/90301

# Functionality
In the case a staff member wants to _remove the visual cue_ that a post has been edited eg.

<img width="86" alt="Screenshot 2023-01-18 at 2 59 12 PM" src="https://user-images.githubusercontent.com/50783505/213293333-9c881229-ab18-4591-b39b-e3419a67907d.png">

while maintaining the changes made in the edits, they can enable the (hidden) site setting of `can_permanently_delete`.
When this is enabled, after _hiding_ the revisions

<img width="149" alt="Screenshot 2023-01-19 at 1 53 35 PM" src="https://user-images.githubusercontent.com/50783505/213546080-2a9e9c55-b3ef-428e-a93d-1b6ba287dfae.png">

there will be an additional button in the history modal to <kbd>Delete revisions</kbd> on a post.

<img width="997" alt="Screenshot 2023-01-19 at 1 49 51 PM" src="https://user-images.githubusercontent.com/50783505/213546333-49042558-50ab-4724-9da7-08bacc68d38d.png">

Since this action is permanent, we display a confirmation dialog prior to triggering the destroy call

<img width="722" alt="Screenshot 2023-01-19 at 1 55 59 PM" src="https://user-images.githubusercontent.com/50783505/213546487-96ea6e89-ac49-4892-b4b0-28996e3c867f.png">

Once confirmed the history modal will close and the post will `rebake` to display an _unedited_ post.

<img width="868" alt="Screenshot 2023-01-19 at 1 56 35 PM" src="https://user-images.githubusercontent.com/50783505/213546608-d6436717-8484-4132-a1a8-b7a348d92728.png">
 
see that there is not a visual que for _revision have been made on this post_ for a post that **HAS** been edited. In addition to this, a user history log for `purge_post_revisions` will be added for each action completed.

# Limits
- Admins are rate limited to 20 posts per minute
2023-01-19 15:09:01 -06:00
Ted Johansson 9cdeb93375
FEATURE: Allow TL4 users to see unlisted topics (#19890)
TL4 users can already list and unlist topics, but they can't see
the unlisted topics. This change brings this to par by allowing
TL4 users to also see unlisted topics.
2023-01-17 16:50:15 +08:00
David Taylor 6417173082
DEV: Apply syntax_tree formatting to `lib/*` 2023-01-09 12:10:19 +00:00
Martin Brennan 56eaf91589
FIX: Do not error when anon user looks at secure upload for deleted post (#19792)
If a secure upload's access_control_post was trashed, and an anon user
tried to look at that upload, they would get a 500 error rather than
the correct 403 because of an error inside the PostGuardian logic.
2023-01-09 16:12:10 +10:00
Alan Guo Xiang Tan 24db6fbb73
PERF: Memoize topic level checks in PostGuardian (#19647)
When loading posts in a topic, the topic level guardian
checks are run multiple times even though all the posts belong to the
same topic. Profiling in production revealed that this accounted for a
significant amount of request time for a user that is not staff or anon.
Therefore, we're optimizing this by adding memoizing the topic level
calls in `PostGuardian`. Speficifally, the result of
`TopicGuardian#can_see_topic?` and `PostGuardian#can_create_post?`
method calls are memoized per topic.

Locally profiling shows a significant improvement for normal users
loading a topic with 100 posts.

Benchmark script command: `ruby script/bench.rb --unicorn --skip-bundle-assets --iterations 100`

Before:

```
topic user:
  50: 114
  75: 117
  90: 122
  99: 209
topic.json user:
  50: 67
  75: 69
  90: 72
  99: 162
```

After:

```
topic user:
  50: 101
  75: 104
  90: 107
  99: 184
topic.json user:
  50: 53
  75: 53
  90: 56
  99: 138
```
2023-01-03 09:00:42 +08:00
Krzysztof Kotlarek 09d15d4c7f
FIX: access to category chat only when user can create post (#19488)
Previously, restricted category chat channel was available for all groups - even `readonly`. From now on, only user who belong to group with `create_post` or `full` permissions can access that chat channel.
2022-12-19 11:35:28 +11:00
Selase Krakani 0ce38bd7bc
SECURITY: Restrict unlisted topic creation (#19259) 2022-12-01 10:26:35 +00:00
Sam 4f63bc8ed2
FEATURE: hidden site setting to suppress unsecured categories from admins (#19098)
The hidden site setting `suppress_secured_categories_from_admin` will
suppress visibility of categories without explicit access from admins
in a few key areas (category drop downs and topic lists)

It is not intended to be a security wall since admins can amend any site
setting. Instead it is feature that allows hiding the categories from the
UI.

Admins will still be able to see topics in categories without explicit
access using direct URLs or flags.

Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
2022-11-18 14:37:36 +11:00
Martin Brennan f8f55cef67
DEV: TODO followups (#18936)
* Remove old bookmark column ignores to follow up b22450c7a8
* Change some group site setting checks to use the _map helper
* Remove old secure_media helper stub for chat
* Change attr_accessor to attr_reader for preloaded_custom_fields to follow up 70af45055a
2022-11-09 07:48:05 +10:00
Alan Guo Xiang Tan a473e352de
DEV: Introduce TopicGuardian#can_see_topic_ids method (#18692)
Before this commit, there was no way for us to efficiently check an
array of topics for which a user can see. Therefore, this commit
introduces the `TopicGuardian#can_see_topic_ids` method which accepts an
array of `Topic#id`s and filters out the ids which the user is not
allowed to see. The `TopicGuardian#can_see_topic_ids` method is meant to
maintain feature parity with `TopicGuardian#can_see_topic?` at all
times so a consistency check has been added in our tests to ensure that
`TopicGuardian#can_see_topic_ids` returns the same result as
`TopicGuardian#can_see_topic?`. In the near future, the plan is for us
to switch to `TopicGuardian#can_see_topic_ids` completely but I'm not
doing that in this commit as we have to be careful with the performance
impact of such a change.

This method is currently not being used in the current commit but will
be relied on in a subsequent commit.
2022-10-27 06:13:21 +08:00
Martin Brennan f5194aadd3
DEV: Remove usages of enable_personal_messages (#18437)
cf. e62e93f83a

This PR also makes it so `bot` (negative ID) and `system` users are always allowed
to send PMs, since the old conditional was just based on `enable_personal_messages`
2022-10-05 10:50:20 +10:00
Roman Rizzi ba139b8c23
REFACTOR: Improve reusability by Decoupling flag modal from flag target. (#18251)
* REFACTOR: Improve reusability by Decoupling flag modal from flag target.

We want chat message's flags to have the same features as topic and posts' flags, but we prefer not having to duplicate core's logic. This PR moves target specific bits to different classes, allowing plugins to flag custom things by
providing their own.

* A couple of fixes for the flag modal:

- Make sure buttons are disabled until a flag type is selected.
- Don't throw an error when checking if the user can undo an action on a deleted topic.
- Disable flagging on deleted topics.
2022-09-29 11:57:36 -03:00
Martin Brennan e62e93f83a
FEATURE: Introduce personal_message_enabled_groups setting (#18042)
This will replace `enable_personal_messages` and
`min_trust_to_send_messages`, this commit introduces
the setting `personal_message_enabled_groups`
and uses it in all places that `enable_personal_messages`
and `min_trust_to_send_messages` currently apply.

A migration is included to set `personal_message_enabled_groups`
based on the following rules:

* If `enable_personal_messages` was false, then set
  `personal_message_enabled_groups` to `3`, which is
  the staff auto group
* If `min_trust_to_send_messages` is not default (1)
  and the above condition is false, then set the
  `personal_message_enabled_groups` setting to
  the appropriate auto group based on the trust level
* Otherwise just set `personal_message_enabled_groups` to
  11 which is the TL1 auto group

After follow-up PRs to plugins using these old settings, we will be
able to drop the old settings from core, in the meantime I've added
 DEPRECATED notices to their descriptions and added them
to the deprecated site settings list.

This commit also introduces a `_map` shortcut method definition
for all `group_list` site settings, e.g. `SiteSetting.personal_message_enabled_groups`
also has `SiteSetting.personal_message_enabled_groups_map` available,
which automatically splits the setting by `|` and converts it into
an array of integers.
2022-09-26 13:58:40 +10:00
communiteq 56555a0231
Disallow access to raw email for non-staff users (#17569) 2022-09-14 09:57:12 +08:00
Bianca Nenciu ec8306835d
FIX: Improvements to like button for archived topics (#17951)
* FIX: Do not allow to remove like if topic is archived

* FIX: Always show like button

The like button used to be hidden if the topic was archived and it had
no likes. This commit changes that to always show the like button, but
with a not-allowed cursor if the topic is archived.
2022-08-22 14:58:02 +03:00
Bianca Nenciu a0537816fb
FIX: Destroy all posts when hard deleting topic (#17359)
Hard deleting topics that contained soft deleted posts or small actions
used to create orphan posts because only the first post was hard
deleted. This commit adds an error message if there are still posts left
in the topic that must be hard deleted first or hard deletes all small
actions too immediately (there is no other way of hard deleting a small
action because there is no wrench menu).
2022-08-10 12:11:50 +03:00
Bianca Nenciu bc476978e8
FIX: Support for group everyone in tag setting (#17669)
The "everyone" group is an automatic group and GroupUser records do not
exist for it. This commit allows all users if the group everyone is one
of the groups in the setting "pm_tags_allowed_for_groups".
2022-07-27 15:44:41 +03:00
Vinoth Kannan eef58f510c
FEATURE: users with no posts shouldn't able to edit username after the allowed period. (#17583)
We are no longer going to let users change their username after the allowed `username_change_period` when there are no posts created by the user.
2022-07-21 04:46:15 +05:30
Krzysztof Kotlarek 09932738e5
FEATURE: whispers available for groups (#17170)
Before, whispers were only available for staff members.

Config has been changed to allow to configure privileged groups with access to whispers. Post migration was added to move from the old setting into the new one.

I considered having a boolean column `whisperer` on user model similar to `admin/moderator` for performance reason. Finally, I decided to keep looking for groups as queries are only done for current user and didn't notice any N+1 queries.
2022-06-30 10:18:12 +10:00
Martin Brennan fcc2e7ebbf
FEATURE: Promote polymorphic bookmarks to default and migrate (#16729)
This commit migrates all bookmarks to be polymorphic (using the
bookmarkable_id and bookmarkable_type) columns. It also deletes
all the old code guarded behind the use_polymorphic_bookmarks setting
and changes that setting to true for all sites and by default for
the sake of plugins.

No data is deleted in the migrations, the old post_id and for_topic
columns for bookmarks will be dropped later on.
2022-05-23 10:07:15 +10:00
Isaac Janzen 1a12e4cfc8
FEATURE: Introduce site setting to allow for non staff pm tagging (#16671)
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
Martin Brennan fbcc35b417
DEV: Remove PostAction/UserAction bookmark refs (#16681)
We have not used anything related to bookmarks for PostAction
or UserAction records since 2020, bookmarks are their own thing
now. Deleting all this is just cleaning up old cruft.
2022-05-10 10:42:18 +10:00
Martin Brennan 222c8d9b6a
FEATURE: Polymorphic bookmarks pt. 3 (reminders, imports, exports, refactors) (#16591)
A bit of a mixed bag, this addresses several edge areas of bookmarks and makes them compatible with polymorphic bookmarks (hidden behind the `use_polymorphic_bookmarks` site setting). The main ones are:

* ExportUserArchive compatibility
* SyncTopicUserBookmarked job compatibility
* Sending different notifications for the bookmark reminders based on the bookmarkable type
* Import scripts compatibility
* BookmarkReminderNotificationHandler compatibility

This PR also refactors the `register_bookmarkable` API so it accepts a class descended from a `BaseBookmarkable` class instead. This was done because we kept having to add more and more lambdas/properties inline and it was very messy, so a factory pattern is cleaner. The classes can be tested independently as well.

Some later PRs will address some other areas like the discourse narrative bot, advanced search, reports, and the .ics endpoint for bookmarks.
2022-05-09 09:37:23 +10:00
Roman Rizzi 54ad50eda1
FIX: Respect the cooldown window when editing a flagged topic. (#16046)
When staff decides to hide a flagged post, and it's the first post on the topic, the post owner shouldn't be able to edit either of them until the cooldown finishes. Edit either of them automatically, unhides the post, and makes the topic visible when there's a flag involved.

Reported on meta: https://meta.discourse.org/t/users-can-edit-flagged-topic-title-when-they-should-not-be-able-to/217796
2022-02-25 11:09:31 -03:00
Alan Guo Xiang Tan 5bd55acf83
FIX: Add DB constraints for post & topic counter cache for `UserStat` (#15626)
Ensures that `UserStat#post_count` and `UserStat#topic_count` does not
go below 0. When it does like it did now, we tend to have bugs in our
code since we're usually coding with the assumption that the count isn't
negative.

In order to support the constraints, our post and topic fabricators in
tests will now automatically increment the count for the respective
user's `UserStat` as well. We have to do this because our fabricators
bypasss `PostCreator` which holds the responsibility of updating `UserStat#post_count` and
`UserStat#topic_count`.
2022-02-07 11:23:34 +08:00
Bianca Nenciu 5e2e178fcf FIX: Hide user's bio if profile is restricted
The bio was sometimes visible in the meta tags even though it it should
not have been.
2022-01-05 10:23:36 +08:00
Angus McLeod df3886d6e5
FEATURE: Experimental support for group membership via google auth (#14835)
This commit introduces a new site setting "google_oauth2_hd_groups". If enabled, group information will be fetched from Google during authentication, and stored in the Discourse database. These 'associated groups' can be connected to a Discourse group via the "Membership" tab of the group preferences UI. 

The majority of the implementation is generic, so we will be able to add support to more authentication methods in the near future.

https://meta.discourse.org/t/managing-group-membership-via-authentication/175950
2021-12-09 12:30:27 +00:00
Dan Ungureanu d420a7b2c8
DEV: Reuse code for TrustLevelAndStaffSetting (#15044)
The code that checked this permission was duplicated everytime a new
settings of this type was added. This commit changes the behavior of
some functionality because some feature checks were bypassed for staff
members.
2021-11-22 20:18:53 +02:00
Bianca Nenciu 0c6f9d7c67
FIX: Show right message when permanently deleting topic (#14717) 2021-10-26 18:31:15 +03:00
Bianca Nenciu c4843fc1c1
FEATURE: Allow admins to permanently delete posts and topics (#14406)
Sometimes administrators want to permanently delete posts and topics
from the database. To make sure that this is done for a good reasons,
administrators can do this only after one minute has passed since the
post was deleted or immediately if another administrator does it.
2021-10-13 12:53:23 +03:00
Andrei Prigorshnev b609f6c11c
FIX: restrict other user's notification routes (#14442)
It was possible to see notifications of other users using routes:
- notifications/responses
- notifications/likes-received
- notifications/mentions
- notifications/edits

We weren't showing anything private (like notifications about private messages), only things that're publicly available in other places. But anyway, it feels strange that it's possible to look at notifications of someone else. Additionally, there is a risk that we can unintentionally leak something on these pages in the future.

This commit restricts these routes.
2021-09-29 16:24:28 +04:00