Searching within a topic currently does not make use of PG search and
we're simply doing an `ilike` against the post raw. Furthermore,
`Post#post_number` is already unique within a topic so the other
ordering will never ever be used. This change simply makes the query
cleaner to read.
This new app event will fire whenever a bookmark is created,
edited, or deleted for a post or topic, and replaces these old
app events which had inconsistent APIs:
* page:bookmark-post-toggled
* topic:bookmark-toggled
When the event is triggered, the arguments are in this order:
1. bookmark - The bookmark record created or changed. Will be null
if the bookmark was deleted.
2. target - Object with target (post or topic) and targetId (post ID
or topic ID)
When inviting a group to a topic, there may be members of
the group already in the topic as topic allowed users. These
can be safely removed from the topic, because they are implicitly
allowed in the topic based on their group membership.
Also, this prevents issues with group SMTP emails, which rely
on the topic_allowed_users of the topic to send to and cc's
for emails, and if there are members of the group as topic_allowed_users
then that complicates things and causes odd behaviour.
We also ensure that the OP of the topic is not removed from
the topic_allowed_users when a group they belong to is added,
as it will make it harder to add them back later.
* DEV: allow composer option to skip jumping to a post on save
* DEV: refactor js safe access in jump logic
Co-authored-by: Jarek Radosz <jradosz@gmail.com>
User API keys (not the same thing as admin API keys) are currently
leaked to redis when rate limits are applied to them since redis is the
backend for rate limits in Discourse and the API keys are included in
the redis keys that are used to track usage of user API keys in the last
24 hours.
This commit stops the leak by using a SHA-256 representation of the user
API key instead of the key itself to form the redis key.
We don't need to manually delete the existing redis keys that contain
unhashed user API keys because they're not long-lived and will be
automatically deleted within 48 hours after this commit is deployed to
your Discourse instance.
This happens because the state of `canLoadMore` is not cleared as the
refresh occurs, which is enough to make the page think a footer should
be displayed.
No tests here because it's tricky to test refreshing and none of our
existing acceptance tests seem to.
This removes all custom controllers and redis/messagebus logic from discourse-presence, and replaces it with core's new PresenceChannel system.
All functionality should be retained. This implementation should scale much better to large numbers of users, reduce the number of HTTP requests made by clients, and reduce the volume of messages on the MessageBus.
For more information on PresenceChannel, see 31db8352
We don't support any browser needing this for very long: https://caniuse.com/?search=selectionStart
I'm keeping some protection so It doesn’t crash but ultimately `element.selectionStart` should be enough.
Im not removing this in the commit, but the `caret_position.js` file seems barely used.
We had code to open the bookmark modal in two places -- the bookmark
list and also from within a topic. This caused the two code paths to
drift, as in the bookmark list we were not passing in the forTopic or
autoDeletePreferences data into the modal, and we were also not refreshing
the bookmark list when the bookmark was deleted from within the modal.
This commit moves the modal opening code into an importable
function from the controllers/bookmark module, and all callers
have to do is pass it an instance of Bookmark and also options
for what to do for the following:
* onAfterSave
* onAfterDelete
* onCloseWithoutSaving
An upstream validation bug in the aws-sdk-sns library could enable RCE under certain circumstances. This commit updates the upstream gem, and adds additional validation to provide defense-in-depth.
The `generate`, `rotate` and `suspicious` auth token logs are now always logged regardless of the `verbose_auth_token_logging` setting because we rely no these to detect suspicious logins.
* [WIP] Simplification of install Guide
Working with @osioke to simplify a few pain areas of the install guide.
Still a Work in progress, More changes incoming.
* Update install wording and links
To improve how it reads for a non-technical user looking to start their first Discourse community
* Update community install link
Update community install link to point to the Meta marketplace so more community contributors can help installs
* Copyedit for Branch change from master to main
* Some minor copyedits
Changes references from master to main
Changes a few commands from `apt-get` to just `apt` and from `yum` to `dnf`
Also added first party reference to yum-cron
Added a small note and steps to perform rebuilds
* Copyedits take #2
more refined details
* Revert community install link and copyedits
Revert community install link, fix typo and add a link to the migration guide
* Remove optional info on maxmind
Remove optional info on maxmind to really simplify the guide and reduce the "yet another thing to configure" issue for self hosters
* fix capitalization
Co-authored-by: Osioke Itseuwa <osioke@users.noreply.github.com>
Co-authored-by: Rishabh <rishabhn@protonmail.com>
Before this fix, jumping to posts using the topic timeline scrollbar
will not update the counts since the topic scrollarea is not rerendered.
Follow-up to db337b10ee
Previously when clicking the Delete button for small action posts
there was no way to recover this post if the action was accidental.
Now if canRecover is true on the post, which it is just after it
is deleted and the post is fetched from the server again, we show
an undo button which calls the recover endpoint for the post.
We also now disallow the editing of the post if it is deleted, and
show the proper deleted red CSS on the small action post when deleted.
This is a follow-up to https://github.com/discourse/discourse/pull/14541. This adds a hidden setting for restoring the old behavior for those users who rely on it. We'll likely deprecate this setting at some point in the future.
This commit removes the recipient's username from the
respond to / participants list that is shown at the bottom
of user notification emails. For example if the recipient's
username was jsmith, and there were participants ljones and
bmiller, we currently show this:
> "reply to this email to respond to jsmith, ljones, bmiller"
or
> "Participants: jsmith, ljones, bmiller"
However this is a bit redundant, as you are not replying to
yourself here if you are the recipient user. So we omit the
recipient user's username from this list, which is only used
in the text of the email and not elsewhere.
Instead of using image-uploader, which relies on the old
UploadMixin, we can now use the uppy-image-uploader which
uses the new UppyUploadMixin which is stable enough and
supports both regular XHR uploads and direct S3 uploads,
controlled by a site setting (default to XHR).
At some point it may make sense to rename uppy-image-uploader
back to image-uploader, once we have gone through plugins
etc. and given a bit of deprecation time period.
This commit also fixes `for_private_message`, `for_site_setting`,
and `pasted` flags not being sent via uppy uploads onto the
UploadCreator, both via regular XHR uploads and also through
external/multipart uploads.
The uploaders changed are:
* site setting images
* badge images
* category logo
* category background
* group flair
* profile background
* profile card background
Instead of leaking ordering of the posts all around the class, we
centralize it in a method making the code easier to understand. In a
future PR, we will also introduce a plugin API to allow custom ordering
and the change in this commit helps to faciliate that.
This commit makes the following change to the Edit Bookmark
modal window for clarity:
* If the user is editing an existing bookmark without a reminder set,
hide the "none needed" option. This will draw more attention to the
delete button.
* If the user is editing an existing bookmark with a reminder set for the
future, change the "none needed" option to say "remove reminder, keep bookmark"
To do this, I needed to provide an option to override the labels
for time shortcuts in certain cases, so I could keep the NONE shortcut
but have the different wording.
