* Revert "DEV: skips three tests following cc1e73 (#13386)"
This reverts commit 2be201660a.
* FIX: Do not refresh post stream twice
This also improves the test suite and simulates a long running request
* FIX: Update local copy of raw
Next Week should mean next Monday, Next Month - the first day of the next month, and so on.
Also, we'll be using the name "Next Monday" instead of "Next Week" because it's easier to understand. No one can get confused by next Monday.
* DEV: skips two tests following cc1e73
Following the fix in cc1e73b8e4 we now refresh the whole stream which causes expected states of these tests to not exist anymore.
I'm skipping theses tests while we decide for a better fix.
We previously only showed the link to the Email section
of group settings if both SMTP and IMAP were enabled for
a site, but this is not necessary now, only SMTP can be
enabled by itself so we should show the section if SMTP
is enabled.
Rendering an empty flair element with the css `background-image: url();` causes the browser to attempt an image request against the current document URL. Making duplicate requests for the document URL can cause some unusual race conditions, especially related to cookies. If this user-avatar-flair element was present on the site homepage (e.g. if categories+latest is the homepage), then it can prevent the signup flow from working correctly.
This commit updates the user-avatar-flair component to be a transparent wrapper around the avatar-flair component. If the user has no flair, no avatar-flair element will be rendered. This avoids the `background-image: url();` situation, and fixes the auth flow.
This commit also removes the duplicate avatar flair rendering from the `latest-topic-list-item` component. This wasn't particularly obvious, since the duplicate flairs were being rendered directly on top of each other.
The problem was happening in component integration tests on the rendering stage, sometimes the rendering would never finish.
Using time moments in the future when faking time solves the problem. Unfortunately, I don't know why exactly it helps. It was just a lucky guess after some hours I spent trying to figure out what's going on. But I've done a lot of testings, so looks like it really works. I'll be monitoring builds for some time after merging this anyway.
Unit tests seem to work alright with moments in the past. And we don't fake time in acceptance tests at the moment but I guess they would very likely be flaky with time moments from the past since they also do rendering.
I'm actually thinking of moving all fake time moments to the future (including moments in unit tests) to decrease the chances of flakiness. But I don't want to do everything in one PR, because I can accidentally introduce new flakiness.
A pretty easy way of picking time moments in the future for tests is to use the 2100 year. It has the same calendar as 2021. If a day is Monday in 2021 it's Monday in 2100 too.
Before this fix if your forum was set up with a subfolder and you
clicked on a link to a different subfolder it would not work. For
example:
subfolder: /cool
link is: /about-us
Previously it would try to resolve /about-us as /cool/about-us. With
this fix it redirects to /about-us correctly.
Editing a post that was just posted caused it to be reloaded and made a
request to the server. This had an additional side effect where the
model instances used by post stream and composer would be different and
changes did not propagate correctly.
Previously due to "rowheader" role we would read out topic titles twice.
This adjusts it so we apply the heading role only to the topic link.
In turn this makes navigation through topic lists more accurate (h) only
lands you on topic links. It also reduces the amount of duplicate reading
NVDA does.
Before:
Topic title link new topic link support link b481 link 19h link 2 button...
After:
Topic title link
This reduces noise, up and down once you land on a topic link can give you
more context.
* UX: Improvements to reorder categories UX
Before, moving a category from, for example, position 25 to position 0 would result in switching the positions of the two categories at those positions.
Category A at position 0 would move to position 25, and Category B at position 25 would move to position 0.
Instead of switching positions, the reorder categories function should retain the order of categories except for the one being moved.
So, Category B at position 25 would still move to position 0, but Category A is merely bumped down to position 1.
This improves the UX because if a user *really* wants to switch the two categories, it results in one extra step. However in the other (what I think is normal) case, it saves the 24 other switches the user has to make to get Category A back to position 1 (you can imagine the user having to click the up arrow button repeatedly to return Category A to the top of the page). Now, imagine trying to do this with a site with 100s of categories. Yikes!
The UX improvement described above is what this commit accomplishes by redesigning the `move()` method of the reorder-categories controller. It adds some overhead to adjust the positions of all categories in between the origin and target positions, but in testing this is not noticible to the user. It's better for the computer to do extra work than the user.
* UX: Allow decimal input in reorder-categories for more precise positioning.
A common UX pattern when reordering a list of items is to allow a user to specify a target position as a decimal between two valid integer positions. The user is indicating they want the target list item to move in between the list items at the positions on either side of the target position.
For example, say there are three categories Category A at position 0, Category B at position 1, and Category C at position 3.
To move Category C in between Categories A and B, a user can now simply update Category C's position to 0.5.
The `ember_jquery` bundle contains production builds of Ember and jQuery
which doesn't work with tests. This commits introduces a new
`theme_qunit_vendor` bundle which is copy of the `vendor` bundle but
doesn't contain `ember_jquery`.
This commit is a partial revert of
409c8585e4
Previously, the `transformed.blah` shortcut could only be used in top-level hbs statements like {{transformed.blah}}. When attempting to use it in a sub-expression like `{{concat "hello" transformed.world}}`, it would raise a "transformed is not defined" error.
This commit updates the shortcut logic to make `transformed.blah` and `attrs.blah` work consistently in all hbs expressions.
Co-authored-by: Jordan Vidrine <jordan@jordanvidrine.com>
We don't want to show the draft checkmark in the composer when drafts are saved, as it’s a little bit distracting to see it keeps appearing and disappearing. Only in the case of error does it need to show anything, we will be showing a "drafts offline" warning as we did it before.
An important detail is that the warning was appearing and disappearing all the time too. Now, the warning won’t be flashing while a user is typing, it’ll be disappearing only when the draft was eventually saved.
I made a change in https://github.com/discourse/discourse/pull/13083/files to suppress re-throwing the error from popupAjaxError if isTesting() but that causes issues in other places instead. If I remove it I get this error in the group email test I added, so I am removing that test here too.
* DEV: replace swipe events to use translate rather than left/right
translate is better for animations. also use native css animations for opening
and closing.
* a11y: respect prefers reduced motion on mobile timeline
* DEV: reduce jquery usage
* DEV: add tests for menu swipe events
test is run in 50% zoom/transform which means offsets and x of touch events need to be halved
Refactor test window to use a transform rather than non-standard zoom property
Co-authored-by: Penar Musaraj <pmusaraj@gmail.com>
A followup to e3b0abc and a replacement PR for #13298.
Fixes long topic titles wrapping to a separate line in the dropdown search results.
Also replaces divs that were incorrectly nested inside spans.
* FIX: Quoting Oneboxed content should exclude formatting
When a post is quoted that includes Oneboxed content, we should not include the formatting generated by the Onebox. Rather, we should attempt to collapse the link referenced by the Onebox to a single line text link.
* DEV: fix tests
Tag-chooser component expects an array of blocked tags, but was passed
a string instead. That made tag-chooser to not allow any tags that were
a substring of the current one.
In Ember CLI addons get put into the vendor bundle, as opposed to their
own bundle like we're doing in the Rails app. We never use pretty-text
without our vendor bundle so this should have no difference on
performance.
We need to keep the pretty-text bundle for server side cooking.
Rather than returning the size of the currently rendered image in the composer window (which is dependent on browser settings such as window size and zoom level), return the actual dimensions of the image file itself.
(Also see commit abac614492 which was an earlier attempt to fix this by excluding Oneboxed images entirely. That was reverted as the CSS selector didn’t work on all browsers.)
If we don't escape periods, they are interpreted as wildcards and it
becomes impossible to visit profiles of other users whose usernames
match. E.g., if your username was `a.c` and attempted to visit `abc`'s
profile, you would be incorrectly redirected to your own profile.
* FIX: Ignore `allowlistgeneric` Onebox image sizes
The size of an image contained within the preview pane of a Composer window may vary depending on the configuration of the browser displaying the Composer (e.g., dimension of browser window, zoom level, etc.).
Presently, the dimensions of the images from the browser creating the post containing the Onebox will be used to render the Onebox to anyone who views the post. It is safer to let the backend figure out the dimensions of the images. Therefore, exclude `.onebox.allowlistedgeneric` images from the list of `image_sizes` sent to the backend.
* DEV: Replace jQuery selector with pure JS
* DEV: remove more jQuery
After editing a post, it is refreshed by two ways. One of them is
triggered by the client side which will route the client to the edited
post and force a reload this way. The other way is via Message Bus.
This commit ignores both of the ways and tries to update the post
immediately and then refresh the post stream.
It was not clear that replace watched words can be used to replace text
with URLs. This introduces a new watched word type that makes it easier
to understand.
I merged this PR in yesterday, finally thinking this was done https://github.com/discourse/discourse/pull/12958 but then a wild performance regression occurred. These are the problem methods:
1aa20bd681/app/serializers/topic_tracking_state_serializer.rb (L13-L21)
Turns out date comparison is super expensive on the backend _as well as_ the frontend.
The fix was to just move the `treat_as_new_topic_start_date` into the SQL query rather than using the slower `UserOption#treat_as_new_topic_start_date` method in ruby. After this change, 1% of the total time is spent with the `created_in_new_period` comparison instead of ~20%.
----
History:
Original PR which had to be reverted **https://github.com/discourse/discourse/pull/12555**. See the description there for what this PR is achieving, plus below.
The issue with the original PR is addressed in 92ef54f402
If you went to the `x unread` link for a tag Chrome would freeze up and possibly crash, or eventually unfreeze after nearly 10 mins. Other routes for unread/new were similarly slow. From profiling the issue was the `sync` function of `topic-tracking-state.js`, which calls down to `isNew` which in turn calls `moment`, a change I had made in the PR above. The time it takes locally with ~1400 topics in the tracking state is 2.3 seconds.
To solve this issue, I have moved these calculations for "created in new period" and "unread not too old" into the tracking state serializer.
When I was looking at the profiler I also noticed this issue which was just compounding the problem. Every time we modify topic tracking state we recalculate the sidebar tracking/everything/tag counts. However this calls `forEachTracked` and `countTags` which can be quite expensive as they go through the whole tracking state (and were also calling the removed moment functions).
I added some logs and this was being called 30 times when navigating to a new /unread route because `sync` is being called from `build-topic-route` (one for each topic loaded due to pagination). So I just added a debounce here and it makes things even faster.
Finally, I changed topic tracking state to use a Map so our counts of the state keys is faster (Maps have .size whereas objects you have to do Object.keys(obj) which is O(n).)
<!-- NOTE: All pull requests should have tests (rspec in Ruby, qunit in JavaScript). If your code does not include test coverage, please include an explanation of why it was omitted. -->
Refactors `TrustLevel` and moves translations from server to client
Additional changes:
* "staff" and "admin" wasn't translatable in site settings
* it replaces a concatenated string with a translation
* uses translation for trust levels in users_by_trust_level report
* adds a DB migration to rename keys of translation overrides affected by this commit
In Ember CLI, the vendor bundler includes Ember/jQuery, so this brings
our app closer to that configuration.
We have a couple pages (Reset Password / Confirm New Email) where we need
`ember_jquery` without vendor so the file still exists for those cases.
Previous to this change we would switch off MessageBus updating after 20
minutes.
This ensures that when the user becomes present again we turn on long polling.
Without long polling updates can be delayed for minutes.
The widget should accept the disabled option.
In that case, CSS class "disabled".
In addition, after click dropdown will not be shown.
Also, the option to disable a specific value in a dropdown is included
…and just prioritize the current one, instead of hiding other categories.
Context: when you open the composer by clicking "New Topic" button when in a category, or by clicking "New Topic" in the share-popup, the category selector shows only the current category and its children (and "Uncategorized"). You can still find other categories, but you have to search by name.
This PR changes that, so you now can see all the categories in the dropdown, and those that are relevant (again: current, children and uncategorized) are displayed before all other categories.
tldr: don't make choosing other categories harder - make choosing relevant ones easier.
1. It defaults to `cache: true` already
2. Setting it to `false` for non-GET request doesn't do anything
3. We were correcting `cache: false` GET requests to use `cache: true`
…so setting it to anything at all, for any type of request doesn't make sense (anymore)
When the client received a new notification, it prioritized only PM
notifications instead of maintaining the priority order. Later, the
check for missing notification deleted all notifications that were
in the wrong order because it could not match the IDs.
The correct order puts high_priority AND unread notifications first.
Low priority or read notifications (including high priority, but read
notifications) come after.
Original PR which had to be reverted **https://github.com/discourse/discourse/pull/12555**. See the description there for what this PR is achieving, plus below.
The issue with the original PR is addressed in 92ef54f402
If you went to the `x unread` link for a tag Chrome would freeze up and possibly crash, or eventually unfreeze after nearly 10 mins. Other routes for unread/new were similarly slow. From profiling the issue was the `sync` function of `topic-tracking-state.js`, which calls down to `isNew` which in turn calls `moment`, a change I had made in the PR above. The time it takes locally with ~1400 topics in the tracking state is 2.3 seconds.
To solve this issue, I have moved these calculations for "created in new period" and "unread not too old" into the tracking state serializer.
When I was looking at the profiler I also noticed this issue which was just compounding the problem. Every time we modify topic tracking state we recalculate the sidebar tracking/everything/tag counts. However this calls `forEachTracked` and `countTags` which can be quite expensive as they go through the whole tracking state (and were also calling the removed moment functions).
I added some logs and this was being called 30 times when navigating to a new /unread route because `sync` is being called from `build-topic-route` (one for each topic loaded due to pagination). So I just added a debounce here and it makes things even faster.
Finally, I changed topic tracking state to use a Map so our counts of the state keys is faster (Maps have .size whereas objects you have to do Object.keys(obj) which is O(n).)
A non-staff user cannot post to a closed topic, so we should not
show them the modal asking "Which topic do you want to reply to?"
This also fixes an issue I ran into while testing the above change, in
Ember CLI an error was being raised because related messages were being
set inside a computed property.
This overhauls the user interface for the group email settings management, aiming to make it a lot easier to test the settings entered and confirm they are correct before proceeding. We do this by forcing the user to test the settings before they can be saved to the database. It also includes some quality of life improvements around setting up IMAP and SMTP for our first supported provider, GMail. This PR does not remove the old group email config, that will come in a subsequent PR. This is related to https://meta.discourse.org/t/imap-support-for-group-inboxes/160588 so read that if you would like more backstory.
### UI
Both site settings of `enable_imap` and `enable_smtp` must be true to test this. You must enable SMTP first to enable IMAP.
You can prefill the SMTP settings with GMail configuration. To proceed with saving these settings you must test them, which is handled by the EmailSettingsValidator.
If there is an issue with the configuration or credentials a meaningful error message should be shown.
IMAP settings must also be validated when IMAP is enabled, before saving.
When saving IMAP, we fetch the mailboxes for that account and populate them. This mailbox must be selected and saved for IMAP to work (the feature acts as though it is disabled until the mailbox is selected and saved):
### Database & Backend
This adds several columns to the Groups table. The purpose of this change is to make it much more explicit that SMTP/IMAP is enabled for a group, rather than relying on settings not being null. Also included is an UPDATE query to backfill these columns. These columns are automatically filled when updating the group.
For GMail, we now filter the mailboxes returned. This is so users cannot use a mailbox like Sent or Trash for syncing, which would generally be disastrous.
There is a new group endpoint for testing email settings. This may be useful in the future for other places in our UI, at which point it can be extracted to a more generic endpoint or module to be included.
* FIX: Improve GitHub folder regexp in Onebox
It used to match any GitHub URL that was not matched by the other GitHub
Oneboxes and it did not do a good job at handling those. With this
change, the generic Onebox will handle the remaining URLs.
* FEATURE: Add Onebox for GitHub Actions
* FEATURE: Add Onebox for PR check runs
* FIX: Remove image from GitHub folder Oneboxes
It is a generic, auto-generated image which does not provide any value.
* DEV: Add tests
* FIX: Strip HTML comments from PR body
* UX: alert screen readers when there is an issue saving a post
Adds a "alert" role to various popup-input-tips.
This means screen reader users can now tell why a post refuses to save.
Also ensures like icon in the "try the like button" has screen reader support
Previously auto focus would only work on modals that include buttons or
inputs.
To avoid a situation where information modals such as keyboard shortcuts
do not get focus, simply focus on the close button as a fallback.
There are two methods which the server uses to verify an invite is being redeemed with a matching email:
1) The email token, supplied via a `?t=` parameter
2) The validity of the email, as provided by the auth provider
Only one of these needs to be true for the invite to be redeemed successfully on the server. The frontend logic was previously only checking (2). This commit updates the frontend logic to match the server.
This commit does not affect the invite redemption logic. It only affects the 'show' endpoint, and the UI.
Previously we had no role set for various topic links, nor did we have any
headers.
This teaches screen readers that topic links in topic lists are to be treated
as H2. We opted for this less radical change cause a change of the element
type would probably result in many broken themes.
Confirmed on NVDA you can very quickly breeze through topic lists now. Minor
edge case is pinned topics which can be a bit annoying due to multiple links.
The previous commits removed reviewables leading to a bad user
experience. This commit updates the status, replaces actions with a
message and greys out the reviewable.
We now bundle Javascript for each theme/plugin separately, and only ship bundles for enabled plugins to the client. Therefore, these disabled_plugins checks are now redundant, and can be removed.
This PR improves the UI of bulk select so that its context is applied to the Dismiss Unread and Dismiss New buttons. Regular users (not just staff) are now able to use topic bulk selection on the /new and /unread routes to perform these dismiss actions more selectively.
For Dismiss Unread, there is a new count in the text of the button and in the modal when one or more topic is selected with the bulk select checkboxes.
For Dismiss New, there is a count in the button text, and we have added functionality to the server side to accept an array of topic ids to dismiss new for, instead of always having to dismiss all new, the same as the bulk dismiss unread functionality. To clean things up, the `DismissTopics` service has been rolled into the `TopicsBulkAction` service.
We now also show the top Dismiss/Dismiss New button based on whether the bottom one is in the viewport, not just based on the topic count.
Not all screen readers treat articles as navigable roles when moving between landmarks. To help with this, we use a `heading` role on the title, with an arbitrary depth of 2 chosen as to not conflict with the main `<h1/>`. Because ARIA roles are used, this change should be entirely non-visual.
While this introduces minor navigation challenges in posts where headers are included, the vast majority of posts don't, and as screen reader users, we're used to mixed headers in longer-form content.
NVDA does not detect HTML5 articles as regions. This explicitly sets a
region with an aria-label denoting post numbers making it much easier to
know where you are in a topic.
Note role: article which is more semantically correct is not respected by
NVDA d/D shortcut, hence the much more generic "region" role.
When slow mode is enabled it's possible to open the slow mode dialog again to disable it or to update slow mode settings. The problem is that in this case, the button for saving still has the label "Enable" which is confusing.
This changes the text on the button from "Enable" to "Update" when slow mode is already enabled.
Based on feedback from Matt Haughey, we don't need to use so many words when describing a deleted topic or post.
Co-authored-by: Martin Brennan <martin@discourse.org>
If reload a page after enabling slow mode and open the slow mode dialog again it would show a slow mode interval but wouldn't show Enabled Until value. This PR fixes it.
It used to allow adding email addresses to a group even if invites were
disabled for the site. This does not allow user to input email address
if they cannot invite.
The second thing this commit improves is the message that is displayed
to the user when they hit the invite rate limit.
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
The problem was we were setting the properties then immediately calling
`refreshRoute` which was being executed before the properties were
settled via the runloop.
> Backtracking re-render refers to a scenario where, in the middle of the rendering process, you have modified something that has already been rendered.
See more details from the Ember team here https://github.com/emberjs/ember.js/issues/13948.
We call _updateInput from init. _updateInput triggers onChangeInput which mutates a date that was given to future-date-input just a moment ago and a rendering cycle wasn't finished yet.
The crash:
```
Uncaught TypeError: Ember.keys is not a function
```
Repro:
- visit home page
- click new topic
- navigate to your messages by clicking your avatar (top right), then enveloppe icon, and finally the bottom chevron
- click New Message
- click cancel in the composer, it should crash
Watched words are always regular expressions, despite watched_words_
_regular_expressions being enabled or not. Internally, wildcard
characters are replaced with a regular expression that matches any non
whitespace character.
This is two fixes:
1. Ember CLI's proxy did not support 3xx redirects so a redirect was
failing.
2. We were not passing query parameters to the `bootstrap.json` endpoint
to correctly handle previewing themes (and other occasional options.)
If you finished reviewing the initially loaded items, and there're more in the queue, load them.
Also, when fast-tracking the pending items updates, use the reviewable_count returned by the perform result. Calling "result.reviewable_count" returns undefines.
This patch remembers the last id for the `file-change` event and uses it
to initialize the client side watcher. This should help fix the issue
where styles are not reloaded client side if the browser refreshed.
Normally we'd use `ember-auto-import` for this, but it's not run on
our admin tree due to the quirky way we load it conditionally.
Instead we'll append it at the bottom like our Rails app does.
* FIX: Ensure the same email cannot be invited twice
When creating a new invite with a duplicated email, the old invite will
be updated and returned. When updating an invite with a duplicated email
address, an error will be returned.
* FIX: not Ember helper does not exist
* FIX: Sync can_invite_to_forum? and can_invite_to?
The two methods should perform the same basic set of checks, such as
check must_approve_users site setting.
Ideally, one of the methods would call the other one or be merged and
that will happen in the future.
* FIX: Show invite to group if user is group owner
Identical callbacks can pile up during tests and cause all sort of weird problems that are difficult to debug. This commit clears registered callbacks after each test.
* FIX: ember-cli proxy subfolder fix
* REFACTOR: put rootURL setup in environment, update baseURL logic for subfolder
Correctly have ember understand and parse relative_url_root and use it in
the dev server
This was needed to fix a bookmark back button issue but it
broke category topic links, causing a full reload. Now it appears
something has changed in core and this is no longer necessary for
the bookmark back button to work, so I am removing it again.
* FIX: Cache missing inline oneboxes
Some inline oneboxes were not cached when the server did not return an
answer for an URL and the queried URL and the absolute URL were
different.
For example, if user typed www.example.com, the client asked the server
for http://www.example.com and if the server returned an empty response,
then the client would keep requesting an inline onebox everytime the
composer changed.
In other words, the key used for reading (the absolute URL) and the one
used for writing (the URL as typed by the user) were not the same when
the server returned an empty response.
* DEV: Check cache before making request
There is another cache check in PrettyText, but that is not enough if
multiple requests are pending. This problem was made obvious in tests,
but can happen for users with slow connections.
* FEATURE: Allow sending a message with invite
It used to be a staff-only feature and this commit makes it available
to everyone who can invite.
* FIX: Inviting to topic uses another email template
This used to be the case, but the extra parameter was lost when we
switched to the new modal.
The user may have changed their category or tag tracking settings since a topic was tracked/watched based on those settings in the past. In that case we need to alter the reason message we show them otherwise it is very confusing for the end user to be told they are tracking a topic because of a category, when they are no longer tracking that category.
For example: "You will see a count of new replies because you are tracking this category." becomes: "You will see a count of new replies because you were tracking this category in the past."
To do this, it was necessary to add tag and category tracking info to current user serializer. I improved the serializer code so it only does 3 SQL queries instead of 9 to get the tracking information for tags and categories for the current user.
It's been awhile since we have supported IE11 so it should be safe to remove
IntersectionObserver now.
From a TODO task in this repo:
> drop when we eventually drop IE11
Announcement of when we removed IE11 support:
https://meta.discourse.org/t/137984/40?u=blake
See: https://meta.discourse.org/t/navigating-back-to-bookmarks/188912/4
Instead of taking the user back to the bookmark list after selecting
a topic and navigating back, the user was navigated back to the page
before that. This is because the topic-link component was missing
the data-auto-route attribute which tells the intercept-click library
not to use DiscourseURL.routeTo to handle the transition (so it is just
handled internally by Ember)
When editing the files for a theme in the admin dashboard, typing "cmd+s" (a common key-binding to save in most text editors) used to engage the browser's default "save page" dialogue.
This commit adds a key-binding to the ace editor that saves the file.
Now, the "cmd+s" (and "ctrl+s" for windows) key-binding does the same action as the save button.
This commit will add CSS classes like `unlisted`, `pinned`, and `unpinned` on the body tag.
* DEV: we no longer using the `categoryClass` & `tagClasses` methods.
* Update app/assets/javascripts/discourse/app/components/add-topic-status-classes.js
Co-authored-by: Joffrey JAFFEUX <j.jaffeux@gmail.com>
- better form
- uses d-footer
- ensure buttons have the same height
Note that to achieve same height for btn without text, I made the choice to go for a minimum height which should work in most cases.
Fixes a bug in user preferences > interface, the light scheme dropdown
was defaulting to "Theme Default" even when the user had selected a
different scheme.
This updates the preview_theme_id preservation logic to use more recent, robust, browser APIs. It also adds support for preserving the `?pp=async-flamegraph` parameter which is proposed in https://github.com/MiniProfiler/rack-mini-profiler/pull/494
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.
We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
- ensures footer buttons are aligned
- prevents focus on close button to be much larger than it should be, note that this fix could impact other modals but the current solution is not working, so better fix it differently if needed
This bug has first been seen when loading similar topics, minimum repro:
- Have a topic named "Something Foo Bar" with a category.
- Call this in console:
```
Discourse.currentUser.store.find("similar-topic", { title: "Something foo bar", raw: "" })
```
- Navigate to latest (no full refresh)
- The category from the topic should have disappeared
The aim of this PR is to improve the topic tracking state JavaScript code and test coverage so further modifications can be made in plugins and in core. This is focused on making topic tracking state changes easier to respond to with callbacks, and changing it so all state modifications go through a single method instead of modifying `this.state` all over the place. I have also tried to improve documentation, make the code clearer and easier to follow, and make it clear what are public and private methods.
The changes I have made here should not break backwards compatibility, though there is no way to tell for sure if other plugin/theme authors are using tracking state methods that are essentially private methods. Any name changes made in the tracking-state.js code have been reflected in core.
----
We now have a `_trackedTopicLimit` in the tracking state. Previously, if a topic was neither new nor unread it was removed from the tracking state; now it is only removed if we are tracking more than `_trackedTopicLimit` topics (which is set to 4000). This is so plugins/themes adding topics with `TopicTrackingState.register_refine_method` can add topics to track that aren't necessarily new or unread, e.g. for totals counts.
Anywhere where we were doing `tracker.states["t" + data.topic_id] = newObject` has now been changed to flow through central `modifyState` and `modifyStateProp` methods. This is so state objects are not modified until they need to be (e.g. sometimes properties are set based on certain conditions) and also so we can run callback functions when the state is modified.
I added `onStateChange` and `onMessageIncrement` methods to register callbacks that are called when the state is changed and when the message count is incremented, respectively. This was done so we no longer need to do things like `@observes("trackingState.states")` in other Ember classes.
I split up giant functions like `sync` and `establishChannels` into smaller functions for readability and testability, and renamed many small functions to _functionName to designate them as private functions which not be called by consumers of `topicTrackingState`. Public functions are now all documented (well...at least ones that are not immediately obvious).
----
On the backend side, I have changed the MessageBus publish events for TopicTrackingState to send back tags and tag IDs for more channels, and done some extra code cleanup and refactoring. Plugins may override `TopicTrackingState.report` so I have made its footprint as small as possible and externalised the main parts of it into other methods.
If the "use_site_small_logo_as_system_avatar" setting is enabled, the site's small logo is displayed as the selected option by the avatar-selector. Choosing a different avatar disables the setting.
When the admin creates a new custom field they can specify if that field should be searchable or not.
That setting is taken into consideration for quick search results.
This PR includes few commits that improve the new "Share Topic" modal: same
icon for notify button as the notification, advanced options are only showed
for staff, but the topic name should be visible to everyone.
This commit allows site admins to run theme tests in production via a new `/theme-qunit` route. When you visit `/theme-qunit`, you'll see a list of the themes/components installed on your site that have tests, and from there you can select a theme or component that you run its tests.
We also have a new rake task `themes:install_and_test` that can be used to install a list of themes/components on a temporary database and run the tests of the themes/components that are installed. This rake task can be useful when upgrading/deploying a Discourse instance to make sure that the installed themes/components are compatible with the new Discourse version being deployed, and if the tests fail you can abort the build/deploy process so you don't end up with a broken site.
The bulk button is normally shown only to staff, which is why we did not
do any explicit permissions check. Now we do display it on the messages
page too, where it is accessible to everyone.
Regression was introduced in c54609.
This ensures the full height composer styling only applies when (window
height - viewport height > 0). Previously it was being wrongly triggered
when that calculation returned a negative number.
This filter hides reviewables with a score lower than the "reviewable_low_priority_threshold" setting. We only use reviewables that already met this threshold to calculate the Medium and High priority filters.
Bianca Nenciu
Andrei Prigorshnev
Joffrey JAFFEUX
Vinoth Kannan
Sam
Dan Ungureanu
Robin Ward
Martin Brennan
Kane York
Jarek Radosz
David Taylor
Alan Guo Xiang Tan
Penar Musaraj
Jeff Wong
Grayden
Osama Sayegh
Mark VanLandingham
jbrw
Régis Hanol
Kris
Arpit Jalan
Jordan Vidrine
Gerhard Schlager
Krzysztof Kotlarek
Roman Rizzi
Faizaan Gagan
Nolan Darilek
Jeff Atwood
Josh Soref
zacholas
Rafael dos Santos Silva
Blake Erickson
Hariraj Venkatesan
webdirektindia