Includes support for flags, reviewable users and queued posts, with REST API
backwards compatibility.
Co-Authored-By: romanrizzi <romanalejandro@gmail.com>
Co-Authored-By: jjaffeux <j.jaffeux@gmail.com>
Previously we relied on the provider name matching the name of the icon. Now icon names are explicitly set. Plugin providers which do not define an icon will get the default "sign-in-alt" icon
Improves usability of header search icon while user is already in full page search in mobile.
Currently, hitting search icon a second time empties input and does not scroll up to show search form.
This commit scrolls up to show form and sets focus on input.
- The test_email job is removed, because it was always being run synchronously (not in sidekiq)
- 34b29f62 added a bypass for critical emails, to match the spec. This removes the bypass, and removes the spec.
- This adapts the specs for 72ffabf6, so that they check for emails being sent
- This reimplements c2797921, allowing test emails to be sent even when emails are disabled
* Revert "FIX: discourse client should know about Logster (#7232)"
This reverts commit bfcbc4d2d6.
* FIX: discourse client should know about Logster (simpler approach)
- s3_force_path_style was added as a Minio specific url scheme but it has never been well supported in our code base.
- Our new migrate_to_s3 rake task does not work reliably with path style urls too
- Minio has also added support for virtual style requests i.e the same scheme as AWS S3/DO Spaces so we can rely on that instead of using path style requests.
- Add migration to drop s3_force_path_style from the site_settings table
* Check if user is a member of a group or if the group has members
this is used in the template to conditionally show the relevant markup
* Check if user is suspended or if they have a bio
this is used in the template to conditionally show the relevant markup
* Simplify group-card template
* Simplify user-card template
* Refactor user and group cards CSS
* Check if user is new or if user is staff
* Style fixes
- round avatar margin
- use a more standard margin for buttons
- adds lighter font color for new users
- makes some suspension text bold (used to be <b> tags in template)
- ensures images in group bio are responsive
* user card template fixes
- adds quotes to link href attributes
- wraps some strings in tags for more consistent styling
* group card fixes
- adds quotes to link href attributes
- fixes membership button login action
- wraps some strings with tags for consistent styling
* closure action fixes
* closure action fix
* uses core variables instead of new colors and removes unused styles
* Uses better property names
1. Remove `cooked` becaused only the blurb is used on the client side to
display search results.
2. Remove `ignored` because the result is not used in anyway when
searching for pots.
## Before
```
Acceptance: Composer::Image resizing buttons: 7985ms
Acceptance: Composer::Edit the first post: 3854ms
Acceptance: Composer::Composer with dirty edit can toggle to another edit: 3707ms
Acceptance: Composer::Composer can toggle between edit and reply: 3704ms
Acceptance: Composer::Tests the Composer controls: 3685ms
Acceptance: Composer::Composer draft with dirty reply can toggle to edit: 3670ms
Acceptance: Composer::Composer can toggle layouts (open, fullscreen and draft): 3278ms
Acceptance: Composer::Switching composer whisper state: 3266ms
Acceptance: Composer::Create a topic with server side errors: 3253ms
Acceptance: Composer::Composer with dirty reply can toggle to edit: 3189ms
Acceptance: Composer::Create a Topic: 3168ms
Acceptance: Composer::Create an enqueued Topic: 2767ms
Acceptance: Composer::Posting on a different topic: 2394ms
Acceptance: Composer::Composer can switch between edits: 2318ms
Acceptance: Composer::Create an enqueued Reply: 2317ms
Acceptance: Composer::Create a Reply: 2292ms
Acceptance: Composer::Checks for existing draft: 1696ms
Acceptance: Composer::Composer can toggle between reply and createTopic: 1415ms
Acceptance: Composer::Composer can toggle whispers: 1296ms
Acceptance: Composer::Loading draft also replaces the recipients: 594ms
```
## After
```
Acceptance: Composer::Composer can toggle layouts (open, fullscreen and draft): 2305ms
Acceptance: Composer::Switching composer whisper state: 2205ms
Acceptance: Composer::Composer draft with dirty reply can toggle to edit: 2185ms
Acceptance: Composer::Composer can toggle between edit and reply: 1719ms
Acceptance: Composer::Composer with dirty edit can toggle to another edit: 1682ms
Acceptance: Composer::Composer with dirty reply can toggle to edit: 1657ms
Acceptance: Composer::Composer can toggle between reply and createTopic: 1412ms
Acceptance: Composer::Posting on a different topic: 1341ms
Acceptance: Composer::Edit the first post: 1327ms
Acceptance: Composer::Create an enqueued Reply: 1306ms
Acceptance: Composer::Composer can toggle whispers: 1265ms
Acceptance: Composer::Composer can switch between edits: 1260ms
Acceptance: Composer::Create a Reply: 1259ms
Acceptance: Composer::Create a topic with server side errors: 1183ms
Acceptance: Composer::Checks for existing draft: 1172ms
Acceptance: Composer::Create a Topic: 1130ms
Acceptance: Composer::Image resizing buttons: 921ms
Acceptance: Composer::Create an enqueued Topic: 731ms
Acceptance: Composer::Tests the Composer controls: 654ms
Acceptance: Composer::Loading draft also replaces the recipients: 540ms
```
That is not a typo... image resizing button went from 8 seconds to 1 second
Fixes two issues:
1. Redirecting to an external origin's path after login did not work
2. User would be erroneously redirected to the external origin after logout
https://meta.discourse.org/t/109755
This refactor addresses the following issues:
1- Moves all relevant logic to the discourse-topic component (matches desktop)
2- Fixes the flicker issue discussed here
3- Fixes a rare occurring issue where tags wrap to a third line if a topic has long category names and lots of tags
4- Fixes header icon jitter on iOS
5- Fixes an issue where sliding out user / hamburger menus on Android leaves the user in a mid-state with half a title and the header panel visible - swiping will now open the menus but have no effect on the header.
6- adds min-width to the small-logo to act as placeholder so that the title doesn't shift if the logo takes a while to load.
Other than that, everything should look and act the same.
* This is causing certain posts to appear in searches incorrectly as `PostSearchData#raw_data` contains the outdated title, category name and tag names.
* Remove use of 0 in favor of `TrustLevel.levels[:newuser]`.
* Consolidate two tests into a single one.
* Test that disabling the feature works.
* Avoid loading full ActiveRecord object in test when we only need to
know the existence of the record.
This reverts commit d1c4981f65.
Per discussion with @coding-horror it was decided this change is to
far reaching.
Instead we will make smaller strategic changes to tooltips that add
value.
This will allow users installing a Discourse PWA to use their active
theme colors on the generated app. Thanks for @mgiuca for the tip.
Also makes the share_target config explicit to silence Chrome warnings
* improved emoji support
- always optimize images as part of the task
- use the unicode standard ordering/naming for sections
* UX: more height for when there are recently used
Migrates email user options to a new data structure, where `email_always`, `email_direct` and `email_private_messages` are replace by
* `email_messages_level`, with options: `always`, `only_when_away` and `never` (defaults to `always`)
* `email_level`, with options: `always`, `only_when_away` and `never` (defaults to `only_when_away`)
* FEATURE: Exposing a way to add a generic report filter
## Why do we need this change?
Part of the work discussed [here](https://meta.discourse.org/t/gain-understanding-of-file-uploads-usage/104994), and implemented a first spike [here](https://github.com/discourse/discourse/pull/6809), I am trying to expose a single generic filter selector per report.
## How does this work?
We basically expose a simple, single generic filter that is computed and displayed based on backend values passed into the report.
This would be a simple contract between the frontend and the backend.
**Backend changes:** we simply need to return a list of dropdown / select options, and enable the report's newly introduced `custom_filtering` property.
For example, for our [Top Uploads](https://github.com/discourse/discourse/pull/6809/files#diff-3f97cbb8726f3310e0b0c386dbe89e22R1423) report, it can look like this on the backend:
```ruby
report.custom_filtering = true
report.custom_filter_options = [{ id: "any", name: "Any" }, { id: "jpg", name: "JPEG" } ]
```
In our javascript report HTTP call, it will look like:
```js
{
"custom_filtering": true,
"custom_filter_options": [
{
"id": "any",
"name": "Any"
},
{
"id": "jpg",
"name": "JPG"
}
]
}
```
**Frontend changes:** We introduced a generic `filter` param and a `combo-box` which hooks up into the existing framework for fetching a report.
This works alright, with the limitation of being a single custom filter per report. If we wanted to add, for an instance a `filesize filter`, this will not work for us. _I went through with this approach because it is hard to predict and build abstractions for requirements or problems we don't have yet, or might not have._
## How does it look like?
## More on the bigger picture
The major concern here I have is the solution I introduced might serve the `think small` version of the reporting work, but I don't think it serves the `think big`, I will try to shed some light into why.
Within the current design, It is hard to maintain QueryParams for dynamically generated params (based on the idea of introducing more than one custom filter per report).
To allow ourselves to have more than one generic filter, we will need to:
a. Use the Route's model to retrieve the report's payload (we are now dependent on changes of the QueryParams via computed properties)
b. After retrieving the payload, we can use the `setupController` to define our dynamic QueryParams based on the custom filters definitions we received from the backend
c. Load a custom filter specific Ember component based on the definitions we received from the backend
* First take
* Add support for sprites in themes
Automatically register any custom icons added via themes or plugins
* Fix theme sprite caching
* Simplify test
* Update lib/svg_sprite/svg_sprite.rb
Co-Authored-By: pmusaraj <pmusaraj@gmail.com>
* Fix /svg-sprite/search request
* FEATURE: Add `IgnoredUsersSummary` daily job
## Why?
This is part of the [Ability to ignore a user feature](https://meta.discourse.org/t/ability-to-ignore-a-user/110254/8).
We want to:
1. Send an automatic group PM that goes out to moderators
2. When {x} users have Ignored the same user, threshold defined by a site setting, default of 5
3. Only send this message every X days which is defined by another site setting
It is not a setting, and only relevant in specs. The new API is:
```
Jobs.run_later! # jobs will be thrown on the queue
Jobs.run_immediately! # jobs will run right away, avoid the queue
```
Since uploads site settings are now backed by an actual upload, we don't
have to reach over the network just to fetch the favicon. Instead, we
can just read the upload directly from disk.
* FEATURE: Add `Top Ignored Users` report
## Why?
This is part of the [Ability to ignore a user feature](https://meta.discourse.org/t/ability-to-ignore-a-user/110254/8), and also part of [this PR](https://github.com/discourse/discourse/pull/7144).
We want to send a System Message daily when a specific count threshold for an ignored is reached. To make this system message informative, we want to link to a report for the Top Ignored Users too.
We can only be sure that an email is sent when we get a mailer in
`ActionMailer::Deliveries`. A couple of tests were actually incorrect
because it didn't flow through our email sender where there are more
conditions in determining whether an email is sent or not.
* FEATURE: Account for `ignored_users` when merging two users
## Why?
This is part of the [Ability to ignore a user feature](https://meta.discourse.org/t/ability-to-ignore-a-user/110254/8).
When we merge two users, we need to account for merging their list of `ignored_users` too.
- Notices are visible only by poster and trust level 2+ users.
- Notices are not generated for non-human or staged users.
- Notices are deleted when post is deleted.
It seems that due to jobs being asynchronous and wrapping code in a
DistributedMutex that by the time we run the
`UserAvatar#update_gravatar!` job that the user/user email might be
destroyed.
This patch checks before a call to `user.email_hash` to make sure
the user and primary email exist to prevent the exception. If not
present, the job exits as there's nothing to do because we are
probably running after the user was destroyed for some reason.
- Open the log file in "append" mode. This avoids issues if the file does not exist (and matches standard rails log behavior)
- Correctly parse the interval logging environment variable
Mods require visibility to everyone group cause category dialogs need to
know about this.
If the site setting `allow moderators to create categories` will not function
without this
Note there is no security expansion of rights here, the group is technically
empty anyway and it always looks exactly the same on all discourse instances
* FEATURE: Add ignored user list to the User's preference page
## Why?
Part of: https://meta.discourse.org/t/ability-to-ignore-a-user/110254
We want to add list of Ignored users under or along with the muted users preferences section.
This way Users can find and update their list of ignored users.
## UI
## Open questions
Two of many options to represent a list of ignored users is that we can:
1. We can represent the ignored user list as a table with the ability to `un-ignore` but NOT to add new ignored users.
2. We can keep it functioning as the `muted user list` where you can `un-ignore` or `ignore` users.
* Adds warnings to the "Edit Category" dialog
* Doesn't hide the "Security" tab on the "Edit Category" dialog anymore. Instead, it shows an explanation why permissions can't be changed.
* Makes the category name translatable
* Hides the category name from the edit dialog (it can be customized by overriding the translation)
* Creates a translation override if the category has been renamed in the past
By default, this does nothing. Two environment variables are available:
- `DISCOURSE_LOG_SIDEKIQ`
Set to `"1"` to enable logging. This will log all completed jobs to `log/rails/sidekiq.log`, along with various db/redis/network statistics. This is useful to track down poorly performing jobs.
- `DISCOURSE_LOG_SIDEKIQ_INTERVAL`
(seconds) Check running jobs periodically, and log their current duration. They will appear in the logs with `status:pending`. This is useful to track down jobs which take a long time, then crash sidekiq before completing.
This disables a bunch of hacks that bypassed "focus" on iOS (cause focus
events that involve a virtual keyboard on iOS cause browser havoc unless
a physical keyboard is attached)
Also will focus on title on new topic
Sadly there is no clean way of detecting a keyboard is connected to an iPad
If the keyboard is connected we want to disable all the touch related hacks
on iOS
This allows iPad users to specify they have a keyboard connected. Setting
is per device.
A first load was happening in route, which was setting properties on controller. These properties were observed on the controller and were triggering a reload of the AdminUser model.
Not only was it doing loading two times it was also sometimes resulting on the controller model refresh end to happen after route has been changed, resulting in a wrong model.
* UX: make composer resize work on touch devices
This also replaces a vendor dependency with a small built-in resize mechanism.
* Make blue bar's larger padding specific to touch devices
This attribute is used when a submit button is out of a form. It makes it explicit which form this button is submitting.
It's currently used in our login modal form.
Attempt to force NGINX to include content length when doing X-SendFile
This does not seem to be required when bypassing NGINX.
Without this header some CDNs may have issues caching
When a new post is triggered via message bus post stream will attempt to load
it, previously the `/topic/TOPIC_ID/posts.json` would unconditionally include
suggested topics, this caused excessive load on the server.
New pattern defaults to exclude suggested and related topics from this API
unless people explicitly ask for suggested.
Negative option was leading to a fair amount of confusion, going forward
if we want to allow selection of emails from user selector it must be
supplied with `allowEmails=true`
This corrects a regression in 1f4ace4f which broke invite by emails and
start PM to email
This commit also:
- removes [+ New Topic] behaviour from share, this feature has been duplicated in composer actions, months ago
- introduces our new experimental spacing standard for css: eg: `s(2)`
- introduces a new panel UI for modals
Do not allow `/u/search/users.json` to list any group matches unless a
specific `term` is specified in the API call.
Adding groups should always be done when an actual search term exists,
blank search is only supported for users within a topic
Following this change when a user hits `@` and is replying to a topic they
will see usernames of people who were last seen and participated in the topic
This is somewhat experimental, we may tweak this, or make it optional.
Also, a regression in a423a938 where hitting TAB would eat a post you were writing:
Eg this would eat a post:
``` text
@hello, testing 123 <tab>
```
https://stackoverflow.com/a/47822599/17174
Chrome 63 and up start ignoring `autofill="off"`
Per: https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
> The tricky part here is that somewhere along the journey of the web autocomplete=off become a default for many form fields, without any real thought being given as to whether or not that was good for users. This doesn't mean there aren't very valid cases where you don't want the browser autofilling data (e.g. on CRM systems), but by and large, we see those as the minority cases. And as a result, we started ignoring autocomplete=off for Chrome Autofill data
So to work around this decision we now explicitly say: autocomplete="discourse"
when we don't want Chrome to randomly fill in addressed (aka. always)
Removing the theme_field JS object when the value was empty caused the server to maintain the previous value, making it impossible to delete the content of a field.
If a theme setting contained invalid SCSS, it would cause an error 500 on the site, with no way to recover. This commit stops loading theme settings in the core stylesheets, and instead only loads the color scheme variables. This change also makes `common/foundation/variables.scss` available to themes without an explicit import.
- These advanced fields are hidden behind an 'advanced' button, so will not affect normal use
- The editor has been refactored into a component, and styling cleaned up so menu items do not overlap on small screens
- Styling has been added to indicate which fields are in use for a theme
- Icons have been added to identify which fields have errors
Co-authored-by: Sam Saffron <sam.saffron@gmail.com>
Co-authored-by: David Taylor <david@taylorhq.com>
This gives more control over the request. In particular we can easily
lookup DNS dynamically, instead of only upon NGINX startup.
Previously, NGINX was looking up IP for the letter avatar service and
caching the CDN IP address, this caused issues if CDN changed IP, in
which letter avatars would be broken till a container restarted.
NGINX config has been updated to add caching. This change will require
a container rebuild.
The proxy will now function in development environments, so the patch
for `letter_avatar_proxy` has been removed.
The webpush gem by default sets the expiration date of the JWT token to exactly 24 hours in the future. That's not really needed because the token isn't reused. And it might cause UnauthorizedRegistration if the server's clock isn't 100% correct, because the maximum allowed value is 24 hours.
We had a missing formats: string on our render partial that caused logs to
spam when CSS files got 404s.
Due to magic discourse_public_exceptions.rb was actually returning the
correct 404 cause it switched format when rendering the error.
