Commit Graph

174 Commits

Author SHA1 Message Date
Selase Krakani f462347e12
DEV: `PostRevisor` helper methods to track topic title and raw revisions (#21918)
Not all revisions involve changes to the actual post/topic content. We
may want to know if a revisions includes the topic title or post raw.

Specifically introducing these for use in the Akismet plugin to
conditionally queue checks.
2023-06-05 18:02:46 +00:00
Sérgio Saquetim 21ec70b509
FIX: Miscellaneous tagging errors (#21490)
* FIX: Displaying the wrong number of minimum tags in the composer

When the minimum number of tags set for the category is larger than the minimum number of tags
set in the category tag-groups, the composer was displaying the wrong value.

This commit fixes the value displayed in the composer to show the max value between the required
for the category and the tag-groups set for the category.

This bug was reported on Meta in https://meta.discourse.org/t/tags-from-multiple-tag-groups-required-only-suggest-select-at-least-one-tag/263817

* FIX: Limiting tags in categories not working as expected

When a category was restricted to a tag group A, which was set to only allow
one tag from the group per topic, selecting a tag belonging only to A returned
other tags from A that also belonged to other group/s (if any).

Example:

Tag group A: alpha, beta, gamma, epsilon, delta
Tag group B: alpha, beta, gamma

Both tag groups set to only allow one tag from the group per topic.

If Category 1 was set to only allow tags from the tag group A, and the first tag
selected was epsilon, then, because they also belonged to tag group B, the tags
alpha, beta, and gamma were still returned as valid options when they should not be.

This commit ensures that once a tag from a tag group that restricts its tags to
one per topic is selected, no other tag from this group is returned.

This bug was reported on Meta in https://meta.discourse.org/t/limiting-tags-to-categories-not-working-as-expected/263143.

* FIX: Moving topics does not prompt to add required tag for new category

When a topic moved from a category to another, the tag requirements
of the new category were not being checked.

This allowed a topic to be created and moved to a category:

- that limited the tags to a tag group, with the topic containing tags
not allowed.
- that required N tags from a tag group, with the topic not containing
the required tags.

This bug was reported on Meta in https://meta.discourse.org/t/moving-tagged-topics-does-not-prompt-to-add-required-tag-for-new-category/264138.

* FIX: Editing topics with tag groups from parents allows incorrect tagging

When there was a combination between parent tags defined in a tag group
set to allow only one tag from the group per topic, and other tag groups
relying on this restriction to combine the children tag types with the
parent tag, editing a topic could allow the user to insert an invalid
combination of these tags.

Example:

Automakers tag group: landhover, toyota
  - group set to limit one tag from the group per topic

Toyota models group: land-cruiser, hilux, corolla

Landhover models group: evoque, defender, discovery

If a topic was initially set up with the tags toyota, land-cruiser it was
possible to edit it by removing the tag toyota and adding the tag landhover
and other landhover model tags like evoque for example.

In this case, the topic would end up with the tags toyota, land-cruiser,
landhover, evoque because Discourse will automatically insert the
missing parent tag toyota when it detects the tag land-cruiser.

This combination of tags would violate the restriction specified in
the Automakers tag group resulting in an invalid combination of tags.

This commit enforces that the "one tag from the group per topic"
restriction is verified before updating the topic tags and also
make sure the verification checks the compatibility of parent tags that
would be automatically inserted.

After the changes, the user will receive an error similar to:
The tags land-cruiser, landhover cannot be used simultaneously.
Please include only one of them.
2023-05-15 17:19:41 -03:00
Bianca Nenciu b73a9a1faa
UX: Various improvements to welcome topic CTA (#21010)
- Update welcome topic copy
- Edit the welcome topic automatically when the title or description changes
- Remove “Create your Welcome Topic” banner/CTA
- Add "edit welcome topic" user tip
2023-05-12 17:09:40 +03:00
Ted Johansson da6295e3d1
FIX: Allow re-flagging of ninja-edited posts (#21360)
What is the problem?

Consider the following timeline:

1. OP starts a topic.
2. Troll responds snarkily.
3. Flagger flags the post as “inappropriate”.
4. Admin agrees and hides the post.
5. Troll ninja-edits the post within the grace period, but still snarky.
6. Flagger flags the post as inappropriate again.

The current behaviour is that the flagger is met with an error saying the post has been reviewed and can't be flagged again for the same reason.

The desired behaviour is after someone has edited a post, it should be flaggable again.

Why is this happening?

This is related to the ninja-edit feature, where within a set grace period no new revision is created, but a new revision is required to flag the same post for the same reason.

So essentially there is a window between the naughty corner cooldown where a flagged post can't be edited, and the ninja-edit grace period, where an edit can be made without a new revision. Posts that are edited within this window can't be re-flagged by the same user.

|-----------------|-------------------------------|
^ Flag accepted   | ~~~~~~~~~~~~~ 🥷🏻 ~~~~~~~~~~~~ |
                  |                               ^ Editing grace period over
                  ^ Naughty corner cooldown over

How does this fix it?

We already create a new revision when ninja-editing a post with a pending flag. The issue above happens only in the case where the flag is already accepted.

This change extends the existing behaviour so that a new revision is created when ninja-editing any flagged post, regardless of the status of the flag. (Deleted flags excluded.)

This should also help with posterity, avoiding situations where a successfully flagged post looks innocuous in the history because it was ninja-edited, and vice versa.
2023-05-04 10:22:07 +08:00
Mark VanLandingham 65f35e1ef2
FEATURE: SiteSetting for creation of small action on tag change (#20812)
This adds a SiteSetting, which when enabled, creates a small_action post for tag/category changes to the topic. It uses `topic.add_moderator_post, and passes raw text in, to describe the change.
2023-04-05 13:31:31 -05:00
Ted Johansson 25a226279a
DEV: Replace #pluck_first freedom patch with AR #pick in core (#19893)
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
David Taylor 6417173082
DEV: Apply syntax_tree formatting to `lib/*` 2023-01-09 12:10:19 +00:00
Alan Guo Xiang Tan 918dd4d635
SECURITY: use rstrip instead of regex gsub to prevent ReDOS (#19737)
`rstrip` implementation is much more performant than regex

Co-authored-by: Krzysztof Kotlarek <kotlarek.krzysztof@gmail.com>
2023-01-05 06:09:17 +08:00
Rafael dos Santos Silva e901403621
FEATURE: API to customize server side composer errors handling in the client side (#19107)
This will be used by plugins to handle the client side of their custom
post validations without having to overwrite the whole composer save
action as it was done in other plugins.

Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
2022-11-21 13:11:29 -03:00
Bianca Nenciu 6b788d7329
FIX: Skip all post validations if necessary (#18625)
When PostRevisor is called with 'skip_validations: true' it can save
the post twice and one of the calls passes the correct 'validate: false'
argument, but the other one does not.
2022-10-19 18:54:32 +03:00
Arpit Jalan 3aaf4dcfd0
FIX: hide welcome topic banner as soon as the welcome topic is edited (#18125)
* FIX: hide welcome topic banner as soon as the welcome topic is edited

This commit adds a message bus listener on client to hide the welcome
topic banner as soon as the welcome topic is edited.

* update test

* only subscribe when show_welcome_topic_banner is true

* Do not lookup for messageBus service if it's not required

* Remove unneeded code

* Cache result for Site.show_welcome_topic_banner

* Update tests per latest changes

* Changes per PR review
2022-09-01 09:44:21 +05:30
Bianca Nenciu 4a996825fd
FIX: Skip job if tag edit notification is disabled (#17508)
Previous commit did not schedule any more new jobs, but the jobs in
queue could still create notifications.

Follow up to commit e8d802eb86.
2022-07-15 15:36:27 +03:00
Bianca Nenciu e8d802eb86
FIX: Check if tags edit notifications are disabled (#17499)
Tag edit notifications are either created by PostActionNotifier or
PostRevisor. PostActionNotifier already checks if the site setting is
enabled. but PostRevisor scheduled a NotifyTagChange job without
checking disable_tags_edit_notifications.
2022-07-15 16:14:46 +10:00
Osama Sayegh 586d572e05
FIX: Don't advance draft sequence when editing topic title (#16002)
This commit handles the edge case where a draft is lost with no warnings if the user edits the title (or category/tags) of a topic while they're replying.to the same topic. Repro steps are as follows:

1. Start replying to a topic and type enough to get a draft saved.
2. Scroll up to the topic title and click the pencil icon next to the topic title, change the title, category and/or tags, and then save the changes.
3. Reload the page and you'll see that the draft is gone.

This happens because we only allow 1 draft per topic per user and when you edit the title of a topic that you're replying to, from the server perspective it'll look like as if you've submitted your reply so it will advance the draft sequence for the topic and delete the draft.

The fix in this commit makes `PostRevisor` skip advancing the draft sequence when a topic's title is edited using the pencil button next to the title.

Internal ticket: t60854.

Co-authored-by: Robin Ward <robin.ward@gmail.com>
2022-02-23 10:39:54 +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
Dan Ungureanu ec3758b573
FIX: Make PostRevisor more consistent (#14841)
* FIX: Preserve field types when updating revision

When a post was edited quickly twice by the same user, the old post
revision was updated with the newest changes. To check if the change
was reverted (i.e. rename topic A to B and then back to A) a comparison
of the initial value and last value is performed. If the check passes
then the intermediary value is dismissed and only the initial value and
the last ones are preserved. Otherwise, the modification is dismissed
because the field returned to its initial value.

This used to work well for most fields, but failed for "tags" because
the field is an array and the values were transformed to strings to
perform the comparison.

* FIX: Reset last_editor_id if revision is reverted

If a post was revised and then the same revision was reverted,
last_editor_id was still set to the ID of the user who last edited the
post. This was a problem because the same person could then edit the
same post again and because it was the same user and same post, the
system attempted to update the last one (that did not exist anymore).
2021-11-09 16:29:37 +02:00
Andrei Prigorshnev 09ad3ed41d
FEATURE: revert disallowing putting URLs in titles for TL0 users (#13970)
This reverts a part of changes introduced by https://github.com/discourse/discourse/pull/13947

In that PR I:
1. Disallowed topic feature links for TL-0 users
2. Additionally, disallowed just putting any URL in topic titles for TL-0 users

Actually, we don't need the second part. It introduced unnecessary complexity for no good reason. In fact, it tries to do the job that anti-spam plugins (like Akismet plugin) should be doing.

This PR reverts this second change.
2021-08-06 20:07:42 +04: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
Jean e7b8e75583
FEATURE: Add post edits count to user activity (#13495) 2021-08-02 10:15:53 -04:00
Martin Brennan 59582102d8
FIX: Rename ninja edit terminology to grace period (#13598)
We renamed the site setting for this long ago, but there
were a few places left in the code base where "ninja edit"
needed to be turned into "grace period". Doing this here
to avoid combatative language.
2021-07-01 11:27:11 +10:00
mintsaxon 7d0d13c32e FEATURE: add slow_mode_prevents_editing setting..
..as per https://meta.discourse.org/t/slow-mode-for-a-category/179574/16
2021-06-28 13:08:10 -04:00
Martin Brennan 292017dd25
FIX: Do not call :post_edited webhook twice when editing OP (#13112)
When editing the first post for the topic we do two AJAX requests
to two separate controllers in this order:

PUT /t/topic-name
PUT /posts/2489523

This causes two post revisor calls, which end up triggering the
:post_edited DiscourseEvent twice. This is then picked up and sent
as a WebHook event twice. However we do not need to send a :post_edited
webhook event if the first post is being edited and topic_changed is
true from the :post_edited DiscourseEvent, because a second event will
shortly come through for just the post.

See https://meta.discourse.org/t/post-webhook-fires-two-times-on-post-edited-for-first-post-in-a-topic/162408

Continued on from https://github.com/discourse/discourse/pull/10590
2021-05-24 09:10:22 +10:00
Martin Brennan afb2b4c6b9
FIX: Update upload secure status when revising posts (#13110)
When uploads are created from the composer (editing or creating a post),
for sites with secure uploads enabled we assume security by default and
that new upload is set to secure. When the post is created, we then
check whether the post uploads _actually_ need to be secure and adjust
accordingly.

We were not doing this when revising a post, so when a new upload was
created when editing a post in a public topic, the secure status stayed
true erroneously causing issues with image previews, among other things.
2021-05-21 13:32:32 +10:00
Roman Rizzi 6b613e3076
FEATURE: Review every post using the review queue. (#12734)
* FEATURE: Review every post using the review queue.

If the `review_every_post` setting is enabled, posts created and edited by regular uses are sent to the review queue so staff can review them. We'll skip PMs and posts created or edited by TL4 or staff users.

Staff can choose  to:

- Approve the post (nothing happens)
- Approve and restore the post (if deleted)
- Approve and unhide the post (if hidden)
- Reject and delete it
- Reject and keep deleted (if deleted)
- Reject and suspend the user
- Reject and silence the user

* Update config/locales/server.en.yml

Co-authored-by: Robin Ward <robin.ward@gmail.com>

Co-authored-by: Robin Ward <robin.ward@gmail.com>
2021-04-21 08:41:36 -03:00
Martin Brennan ea6f9af08b
FIX: Add topic_diff to PostRevisor (#12518)
The instance of the PostRevisor is passed to the post_edited
event. It is useful to know what has happened to the topic in
this event (we already pass a boolean for topic_changed? but that
is not so helpful by itself).
2021-03-25 10:24:50 +10:00
Mark VanLandingham 371afc45e0
DEV: API for plugins to add post update params and handlers (#12505) 2021-03-24 10:22:16 -05:00
Krzysztof Kotlarek 38ab45cb93
FIX: check min tag count requirement when change category (#12252)
When a category is created, we can set `minimum_required_tags` property.

When the topic is created, we are checking that field and ensuring that the minimum amount of tags were added - unless topic created by a staff member.

Problem is that validation is skipped when we change the category from for example category with 0 tags required to the category with 1 tag required.

Changing category is kind of the unicorn as it is a complicated operation:

https://github.com/discourse/discourse/blob/master/lib/post_revisor.rb#L84

https://github.com/discourse/discourse/blob/master/app/models/topic.rb#L911

https://github.com/discourse/discourse/blob/master/app/models/topic.rb#L823

Before we start to try to change the category, we should ensure that the tags requirement is fulfilled.

https://meta.discourse.org/t/the-category-setting-for-tags-is-not-respected/181214
2021-03-03 10:59:23 +11:00
Krzysztof Kotlarek a1aa37758c
FIX: do not notify when the hidden tag is added or removed (#12025)
The bug was mentioned on meta https://meta.discourse.org/t/users-are-seeing-handling-of-unhandled-tag-again/155367

It was related to users who are watching a specific topic. In that case, when the hidden tag was added or removed to the topic they were notified by `NotifyTagChangeJob`.

That job should take hidden tags into consideration. If all changed tags are in a hidden group, it should exclude user not belong to that group.

At the same time, if visible to anyone tag is added or removed users watching topic should be notified.
2021-02-11 10:03:45 +11:00
Bianca Nenciu 8536521a72
DEV: Add DiscourseEvent before post changes are published (#11759)
This can be used to add to the message notifying the client about the
update.
2021-01-20 10:51:31 +02:00
Krzysztof Kotlarek da2a61e36c
FIX: correct tracking when mute all categories (#11441)
Currently, we have a solution for muted topics. Basically, when a post is created first we send a `muted` message to users who muted that specific topic:

https://github.com/discourse/discourse/blob/master/app/models/topic_tracking_state.rb#L91

Later, topic tracking state filters if the topic is muted or not before update state:

https://github.com/discourse/discourse/blob/master/app/assets/javascripts/discourse/app/models/topic-tracking-state.js#L58:L67

That solution works quite well.

I wanted to extend it to handle `mute all categories by default` setting as well.

In that case, we should only inform the user about new topic/post when they explicitly want to.

If that setting is enabled, we would send "unmuted" message to a user who watches specific category, topic or tag. In all other cases, don't inform user about new topic as all categories are muted by default.

Meta: https://meta.discourse.org/t/threads-muted-by-mute-all-by-default-are-showing-up-as-new-but-not-visible/168324
2020-12-10 16:49:05 +11: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
Gerhard Schlager 81395be4c1 FIX: Ensure uploads are linked to post when revising a post
Editing a post didn't update the `post_uploads` right away. Instead it relied on the `CookedPostProcessor`. This can lead to an inconsistent state if uploads are added or removed during an edit and, for some reason, the `ProcessPost` job doesn't run (successfully). This inconsistency leads to missing uploads, because the newly added uploads appear to be unused and will be deleted by the `CleanUpUploads` job. In addition to that, uploads, which got removed during the edit, appear to be still in use and won't be deleted by the background job.

This commit ensures that the `post_uploads` are updated during the edit without relying on a background job.
2020-09-11 11:49:15 +02:00
jbrw 2aec92d0b4
FEATURE - allow Group Moderators to edit category description (#10292)
Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
2020-07-23 09:50:00 -04:00
Dan Ungureanu c72bc27888
FEATURE: Implement support for IMAP and SMTP email protocols. (#8301)
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
2020-07-10 12:05:55 +03:00
Michael Brown d9a02d1336
Revert "Revert "Merge branch 'master' of https://github.com/discourse/discourse""
This reverts commit 20780a1eee.

* SECURITY: re-adds accidentally reverted commit:
  03d26cd6: ensure embed_url contains valid http(s) uri
* when the merge commit e62a85cf was reverted, git chose the 2660c2e2 parent to land on
  instead of the 03d26cd6 parent (which contains security fixes)
2020-05-23 00:56:13 -04:00
Jeff Atwood 20780a1eee Revert "Merge branch 'master' of https://github.com/discourse/discourse"
This reverts commit e62a85cf6f, reversing
changes made to 2660c2e21d.
2020-05-22 20:25:56 -07:00
Martin Brennan f9d55b4941
FEATURE: Update the topic excerpt when the OP is rebaked (#9852)
* We now have a site setting "topic_excerpt_maxlength" that is used when the OP is created or revised to generate a topic excerpt.
* However, posts created before this setting was introduced cannot benefit from this change unless they are revised, and if the topic excerpt length setting is changed that situation is also not covererd.
* This PR makes a change to rebake! to update the topic excerpt IF the post is the OP.
2020-05-22 13:04:15 +10:00
Kane York 869f9b20a2
PERF: Dematerialize topic_reply_count (#9769)
* PERF: Dematerialize topic_reply_count

It's only ever used for trust level promotions that run daily, or compared to 0. We don't need to track it on every post creation.

* UX: Add symbol in TL3 report if topic reply count is capped

* DEV: Drop user_stats.topic_reply_count column
2020-05-14 15:42:00 -07:00
Guo Xiang Tan f293b28198
FEATURE: Pass instance of revisor to `post_edited` DiscourseEvent. 2020-05-11 16:45:40 +08:00
Krzysztof Kotlarek 9bff0882c3
FEATURE: Nokogumbo (#9577)
* FEATURE: Nokogumbo

Use Nokogumbo HTML parser.
2020-05-05 13:46:57 +10:00
Krzysztof Kotlarek 37e93914fc
FIX: the muted message should be sent after edit (#9593)
Recently, we added feature that we are sending `/muted` to users who muted specific topic just before `/latest` so the client knows to ignore those messages - https://github.com/discourse/discourse/pull/9482

Same `/muted` message should be included when the post is edited
2020-05-01 08:33:57 +10:00
Jarek Radosz 17cf300b71
DEV: Use more specific error responses (#9472)
* DEV: Use `render_json_error` (Adds specs for Admin::GroupsController)
* DEV: Use a specific error on blank category slug (Fixes a `render_json_error` warning)
* DEV: Use a specific error on reviewable claim conflict (Fixes a `render_json_error` warning)
* DEV: Use specific errors in Admin::UsersController (Fixes `render_json_error` warnings)
* FIX: PublishedPages error responses
* FIX: TopicsController error responses (There was an issue of two separate `Topic` instances for the same record. This makes sure there's only one up-to-date instance.)
2020-04-21 03:50:20 +02:00
Dan Ungureanu 0754c7c404
FIX: Various fixes to support posts with no user (#8877)
* Do not grant badges for posts with no user
* Ensure instructions are correct in Change Owner modal
* Hide user-dependent actions from posts with no user
* Make PostRevisor work with posts with no user
* Ensure posts with no user can be deleted
* discourse-narrative-bot should ignore posts with no user
* Skip TopicLink creation for posts with no user
2020-03-11 14:03:20 +02:00
Dan Ungureanu 8eae7d2799
DEV: Improve code readability (#8967)
Follow-up to b0f72ca1 and 8e27fa1b.
2020-02-14 13:05:52 +02:00
Dan Ungureanu 82c84c5141
PERF: Memoize PostRevisor#diff_size (#8939)
Although this method is usually called twice, its execution can take
about 1s.
2020-02-12 19:47:48 +02:00
Dan Ungureanu 8e27fa1bd8
PERF: Optimize post editing
Reordering the conditions reduced the execution time by a factor of 5.
2020-02-12 15:53:28 +02:00
Vinoth Kannan b0f72ca1d6 DEV: improve the code readability.
a0e0b1ef4b
2020-02-11 23:11:59 +05:30
Vinoth Kannan a0e0b1ef4b FIX: reset `edit_reason` in posts when creating a new version. 2020-02-07 09:40:16 +05:30
Mark VanLandingham 20e3c0f386
FIX: Post reviser picking up edits for hidden posts (#8792) 2020-01-27 10:05:48 -06:00
Joffrey JAFFEUX 0d3d2c43a0
DEV: s/\$redis/Discourse\.redis (#8431)
This commit also adds a rubocop rule to prevent global variables.
2019-12-03 10:05:53 +01:00