Commit Graph

271 Commits

Author SHA1 Message Date
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
Arpit Jalan 419d71abcb
FEATURE: allow admin to delete all posts by a user irrespectively (#14128)
This commit allows admin to delete all posts by a user irrespective of
site settings `delete_user_max_post_age` and `delete_all_posts_max`.
2021-08-25 10:14:22 +05:30
Martin Brennan d295a16dab
FEATURE: Uppy direct S3 multipart uploads in composer (#14051)
This pull request introduces the endpoints required, and the JavaScript functionality in the `ComposerUppyUpload` mixin, for direct S3 multipart uploads. There are four new endpoints in the uploads controller:

* `create-multipart.json` - Creates the multipart upload in S3 along with an `ExternalUploadStub` record, storing information about the file in the same way as `generate-presigned-put.json` does for regular direct S3 uploads
* `batch-presign-multipart-parts.json` - Takes a list of part numbers and the unique identifier for an `ExternalUploadStub` record, and generates the presigned URLs for those parts if the multipart upload still exists and if the user has permission to access that upload
* `complete-multipart.json` - Completes the multipart upload in S3. Needs the full list of part numbers and their associated ETags which are returned when the part is uploaded to the presigned URL above. Only works if the user has permission to access the associated `ExternalUploadStub` record and the multipart upload still exists.

  After we confirm the upload is complete in S3, we go through the regular `UploadCreator` flow, the same as `complete-external-upload.json`, and promote the temporary upload S3 into a full `Upload` record, moving it to its final destination.
* `abort-multipart.json` - Aborts the multipart upload on S3 and destroys the `ExternalUploadStub` record if the user has permission to access that upload.

Also added are a few new columns to `ExternalUploadStub`:

* multipart - Whether or not this is a multipart upload
* external_upload_identifier - The "upload ID" for an S3 multipart upload
* filesize - The size of the file when the `create-multipart.json` or `generate-presigned-put.json` is called. This is used for validation.

When the user completes a direct S3 upload, either regular or multipart, we take the `filesize` that was captured when the `ExternalUploadStub` was first created and compare it with the final `Content-Length` size of the file where it is stored in S3. Then, if the two do not match, we throw an error, delete the file on S3, and ban the user from uploading files for N (default 5) minutes. This would only happen if the user uploads a different file than what they first specified, or in the case of multipart uploads uploaded larger chunks than needed. This is done to prevent abuse of S3 storage by bad actors.

Also included in this PR is an update to vendor/uppy.js. This has been built locally from the latest uppy source at d613b849a6. This must be done so that I can get my multipart upload changes into Discourse. When the Uppy team cuts a proper release, we can bump the package.json versions instead.
2021-08-25 08:46:54 +10:00
Andrei Prigorshnev 0c0a11b66a
FEATURE: Disallow putting urls in the title for TL-0 users (#13947)
This disallows putting URLs in topic titles for TL0 users, which means that:

If a TL-0 user puts a link into the title, a topic featured link won't be generated (as if it was disabled in the site settings)
Server methods for creating and updating topics will be refusing featured links when they are called by TL-0 users
TL-0 users won't be able to put any link into the topic title. For example, the title "Hey, take a look at https://my-site.com" will be rejected.

Also, it improves a bit server behavior when creating or updating feature links on topics in the categories with disabled featured links. Before the server just silently ignored a featured link field that was passed to him, now it will be returning 422 response.
2021-08-05 13:38:39 +04:00
Andrei Prigorshnev 5a2ad7e386
DEV: remove calls to guardian from GroupActionLogger (#13835)
We shouldn't be checking if a user is allowed to do an action in the logger. We should be checking it just before we perform the action. In fact, guardians in the logger can make things even worse in case of a security bug. Let's say we forgot to check user's permissions before performing some action, but we still have a call to the guardian in the logger. In this case, a user would perform the action anyway, and this action wouldn't even be logged!

I've checked all cases and I confirm that we're safe to delete this calls from the logger.

I've added two calls to guardians in admin/user_controller. We didn't have security bugs there, because regular users can't access admin/... routes at all. But it's good to have calls to guardian in these methods anyway, neighboring methods have them.
2021-07-28 15:04:04 +04:00
Neil Lalonde b0f06b8ed0
FIX: don't allow category and tag tracking settings on staged users (#13688)
Configuring staged users to watch categories and tags is a way to sign
them up to get many emails. These emails may be unwanted and get marked
as spam, hurting the site's email deliverability.
Users can opt-in to email notifications by logging on to their
account and configuring their own preferences.

If staff need to be able to configure these preferences on behalf of
staged users, the "allow changing staged user tracking" site setting
can be enabled. Default is to not allow it.

Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
2021-07-16 14:50:40 -04:00
Guhyoun Nam 0dc96ce817
FEATURE: Setting to allow moderators to change post ownership (#13708) 2021-07-13 09:40:11 -05:00
Bianca Nenciu 715ecabd85
FIX: TL4 users cannot delete others posts (#13554) 2021-06-30 15:51:35 +03:00
Alan Guo Xiang Tan ff1c53dd6f FIX: Missing category edit icon.
Follow-up to 0e4b8c5318
2021-06-28 10:54:23 +08:00
Alan Guo Xiang Tan 0e4b8c5318 PERF: Cache categories in Site model take 3.
Previous attempt resulted in custom fields going missing in the
serialized output.

This reverts commit 83a6ad32ff.
2021-06-24 13:30:51 +08:00
Kane York 83a6ad32ff Revert "PERF: Cache categories in Site model take 2."
This reverts commit 06fa1efd3d.

Breakage in solved plugin
2021-06-21 12:25:04 -07:00
Bianca Nenciu e70e8d8d8f
FIX: TL4 users can see their deleted posts (#13364) 2021-06-21 19:10:02 +03:00
Alan Guo Xiang Tan 06fa1efd3d PERF: Cache categories in Site model take 2.
Follow-up to aa4f0aee67.

Fixed the security problem in the previous attempt.
2021-06-21 09:47:05 +08:00
Alan Guo Xiang Tan aa4f0aee67 Revert "PERF: Cache categories in Site model."
This reverts commit 7dc0f88acd.
2021-06-17 15:20:35 +08:00
Alan Guo Xiang Tan 7dc0f88acd PERF: Cache categories in Site model.
Profiling showed that we were roughly 10% of a request time creating all
the ActiveRecord objects for categories in the `Site` model on a site with 61 categories.
Instead of querying for the categories each time based on which categories the user can see,
we can just preload all of the categories upfront and filter out the
categories that the user can not see.
2021-06-17 13:17:42 +08:00
Kane York c780ae9d25
FEATURE: Add a messages view for all official warnings of a user (#12659)
Moderators are allowed to see the warnings list, with an access warning.

https://meta.discourse.org/t/why-arent-warnings-easily-accessible-like-suspensions-are/164043
2021-06-14 14:01:17 -07:00
Roman Rizzi a5fddd5cdb
FIX: Hide a post's pending flag count from TL4 users. (#13129)
They can't see the review queue, so there's no reason to show a button with the post's pending flag count in the post controls.
2021-05-26 12:58:00 +10:00
Josh Soref 59097b207f
DEV: Correct typos and spelling mistakes (#12812)
Over the years we accrued many spelling mistakes in the code base. 

This PR attempts to fix spelling mistakes and typos in all areas of the code that are extremely safe to change 

- comments
- test descriptions
- other low risk areas
2021-05-21 11:43:47 +10:00
Joffrey JAFFEUX 374ff4c54c
FIX: topic might be night at this stage (#12929) 2021-05-03 10:37:43 +02:00
Régis Hanol bea1fc1ab8
FEATURE: TL4 & category moderators can merge posts (#12843)
This gives TL4 users and category moderators the ability to merge posts in topics they have moderation privileges.
2021-04-27 18:24:27 +02:00
Martin Brennan eeaecd4fd2
FEATURE: Category setting to allow unlimited first post edits by the owner of the topic (#12690)
This PR adds a new category setting which is a column in the `categories` table, `allow_unlimited_owner_edits_on_first_post`.

What this does is:

* Inside the `can_edit_post?` method of `PostGuardian`, if the current user editing a post is the owner of the post, it is the first post, and the topic's category has `allow_unlimited_owner_edits_on_first_post`, then we bypass the check for `LimitedEdit#edit_time_limit_expired?` on that post.
* Also, similar to wiki topics, in `PostActionNotifier#after_create_post_revision` we send a notification to all users watching a topic when the OP is edited in a topic with the category setting `allow_unlimited_owner_edits_on_first_post` enabled.

This is useful for forums where there is a Marketplace or similar category, where topics are created and then updated indefinitely by the OP rather than the OP making new topics or additional replies. In a way this acts similar to a wiki that only one person can edit.
2021-04-14 15:54:09 +10:00
jbrw ac7773a30d
FEATURE: allow category group moderators to pin/unpin topics (#12325)
* FEATURE: allow category group moderators to pin/unpin topics

Category group moderators should be able to pin/unpin any topics within a category where they have appropraite category group moderator permissions.
2021-03-09 16:05:11 -05:00
Arpit Jalan a174c8b8d4
FIX: hide sso payload behind a button click and log views (#12110) 2021-02-17 21:27:51 +05:30
David Taylor 821bb1e8cb
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978)
The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense.

This commit aims to:
- Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_`
- Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices
- Copy `site_settings` database records to the new names
- Rename relevant translation keys
- Update relevant translations

This commit does **not** aim to:
- Rename any Ruby classes or methods. This might be done in a future commit
- Change any URLs. This would break existing integrations
- Make any changes to the protocol. This would break existing integrations
- Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately

The risks are:
- There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical.
- If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working.

A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 10:04:33 +00:00
Dan Ungureanu dd175537f3
FIX: Existing shared drafts should be accessible (#11915)
Disabling shared drafts used to leave topics in an inconsistent state
where they were not displayed as shared drafts and thus there was no
way of publishing them. Moreover, they were accessible just to users
who have permissions to create shared drafts.

This commit adds another permission check that is used for most
operations and the old can_create_shared_draft? remains used just when
creating a new shared draft.
2021-02-01 16:16:34 +02:00
Martin Brennan 2404fa7a23
DEV: Split toggle topic close job (#11679)
Splits the `ToggleTopicClosed` job into two distinct `OpenTopic` and `CloseTopic` jobs to make the code clearer. The old job cannot be deleted yet because of outstanding sidekiq schedules, so a todo has been added to do so later this year.

Also replaced mentions of `topic_status_update` with `topic_timer` in some files, because the `topic_status_update` model is obsolete and replaced by topic timer.

Added some shortcut methods for checking if a topic is open/whether a user can change an open topic.
2021-01-13 08:49:29 +10:00
Arpit Jalan 25b4e82601
FEATURE: allow disabling self-deletions of posts (#11668)
https://meta.discourse.org/t/restoring-deleted-messages/173647/6?u=techapj
2021-01-08 20:35:13 +05:30
Sam 1cd6ff15dc
PERF: optimize homepage and topic performance (#11607)
These are a few small tweaks that slightly improve performance.

- we omitted 1 query from the post guardian which could cause an N+1
- cook_url has been sped up a bit
- url helper avoids re-creating sets for no reason
2020-12-30 13:08:02 +00:00
Roman Rizzi b45a30c40f
FIX: Users without shared drafts access can still have access to the category. (#11476)
This is an edge-case of 9fb3629. An admin could set the shared draft category to one where both TL2 and TL3 users have access but only give shared draft access to TL3 users. If something like this happens, we need to make sure that TL2 users won't be able to see them, and they won't be listed on latest.

Before this change, `SharedDrafts` were lazily created when a destination category was selected. We now create it alongside the topic and set the destination to the same shared draft category.
2020-12-14 16:08:20 -03:00
jbrw 773c51a633
FEATURE: Allow category group moderators to list/unlist topics (#11470)
* FEATURE: Allow categroy group moderators to list/unlist topics

If enabled via SiteSettings, a user belonging to a group which has been granted category group moderator privileges should be able to list/unlist topics belonging to the appropraite category.
2020-12-14 11:01:22 -05:00
Roman Rizzi 9fb36290e3
FEATURE: Non-staff users can use shared drafts. (#11329)
You can let non-staff users use shared drafts by modifying the `shared_drafts_min_trust_level` site setting. These users must have access to the shared draft category.
2020-12-03 11:07:57 -03:00
jbrw 1c87038255
FEATURE: Allow Category Group Moderators to edit topic titles (#11340)
* FEATURE: Allow Category Group Moderators to edit topic titles

Adds category group moderators to the topic guardian’s `can_edit` method.

The value of `can_edit` is returned by the topic view serializer, and this value determines whether the current user can edit the title/category/tags of the topic directly (which category group moderators could already do by editing the first post of a topic).

Note that the value of `can_edit` is now always returned by the topic view serializer (ie, for both true and false values) to cover the case where a topic is moved out of a category that a category group moderator has permissions on, so that when the topic is reloaded the UI picks up that `can_edit` is now false, and thus the edit icon should no longer be displayed.

* DEV: Add a comment explaining why `can_edit` is always returned
2020-12-02 17:21:59 -05:00
Arpit Jalan 00b41437b0
FIX: hide sso email behind a button click and log views (#11186) 2020-11-11 00:42:44 +05:30
jbrw bba73fc15e
FEATURE: Allow category group moderators to delete topics (#11069)
* FEATURE - allow category group moderators to delete topics

* Allow individual posts to be deleted

* DEV - refactor for new `can_moderate_topic?` method
2020-11-05 12:18:26 -05:00
Roman Rizzi 2f32336081
FIX: Staff can create and edit posts even if a topic is in slow mode. (#11057)
Additionally, ninja edits are no longer restricted.
2020-10-28 16:47:50 -03:00
jbrw ce76553010
FEATURE: allow category group moderators to edit posts (#11005)
* FEATURE: allow category group moderators to edit posts

If the `enable_category_group_moderation` SiteSetting is enabled, posts should be editable by those belonging to the appropraite groups.
2020-10-23 12:37:44 -04:00
jbrw ac31fe8321
FEATURE - SiteSetting to disable user option to hide their profiles and presences (#10885)
* FEATURE - SiteSetting to disable user option to hide their profiles and presences
2020-10-09 17:18:44 -04:00
Bianca Nenciu 318efa8093
FIX: Always let moderators to see their group PMs (#10813)
When enable_personal_messages was disabled, moderators could not see
the private messages for the "moderators" group. The link was displayed
on the client side, but the checks on the server side did not allow it.
2020-10-05 19:38:08 +03:00
Mark VanLandingham 9f73e8779d
FIX: Only staff can edit topic details when first post is locked (#10729) 2020-09-23 11:13:18 -05:00
Penar Musaraj 273db57d6e
FEATURE: Allow admins to delete user SSO records in the UI (#10669)
Also displays the user's last payload in the admin UI to help with debugging SSO issues.
2020-09-15 10:00:10 -04:00
Guo Xiang Tan 0398271f87
FIX: Admin should always be able to view group messages.
Follow-up to b0f22f2523.

Before this fix, `SiteSetting.enable_personal_messages = false` will
prevent admin from viewing group messages.
2020-09-09 08:58:21 +08:00
Blake Erickson 4395e4d165 FIX: Sending a PM through a flag on a deleted post
Because we allow all the other flag types on a deleted post we should be
able to send a pm to the user letting them know why we deleted their
post.

Bug report:

https://meta.discourse.org/t/-/161156
2020-08-19 17:36:52 -06:00
jbrw aa1fc01307
FEATURE - Moderators can create and manage groups (#10432)
Enabling the moderators_manage_categories_and_groups site setting will allow moderator users to create/manage groups.

* show New Group form to moderators

* Allow moderators to update groups and read logs, where appropriate

* Rename site setting from create -> manage

* improved tests

* Migration should rename old log entries

* Log group changes, even if those changes mean you can no longer see the group

* Slight reshuffle

* RouteTo /g if they no longer have permissions to view group
2020-08-19 10:41:40 -04:00
jahan-ggn 65649eaef0
User card settings (#10302)
* settings implemented

* prettier

* settings updated

* rubocop

* prettier

* Revert "rubocop"

This reverts commit 7805145a7d.

* Revert "prettier"

This reverts commit 2c53f4fa12.

* settings updated and changed

* rubocop

* changes applied

* final changes done

* Server side feature added

* spec changed

* changed user_updater and profile file

* Fix user card specs

* web hook serializer solved

* site-setting changed

Co-authored-by: Mark VanLandingham <markvanlan@gmail.com>
2020-08-17 12:37:45 -04:00