We noticed this with the house ads plugin. It inserted content after a
post, which was not taken into account when calculating and memoizing
the height of the element.
Co-authored-by: nlalonde
Co-authored-by: pmusaraj
This is a feature that used to be present in discourse-assign but is
much easier to implement in core. It also allows a topic to be assigned
without it claiming for review and vice versa and allows it to work with
category group reviewers.
We found score hard to understand. It is still there behind the scenes
for sorting purposes, but it is no longer shown.
You can now filter by minimum priority (low, med, high) instead of
score.
This change shows a notification number besides the flag icon in the
post menu if there is reviewable content associated with the post.
Additionally, if there is pending stuff to review, the icon has a red
background.
We have also removed the list of links below a post with the flag
status. A reviewer is meant to click the number beside the flag icon to
view the flags. As a consequence of losing those links, we've removed
the ability to undo or ignore flags below a post.
`Upload#url` is more likely and can change from time to time. When it
does changes, we don't want to have to look through multiple tables to
ensure that the URLs are all up to date. Instead, we simply associate
uploads properly to `UserProfile` so that it does not have to replicate
the URLs in the table.
This change automatically resizes icons for various purposes. Admins can now upload `logo` and `logo_small`, and everything else will be auto-generated. Specific icons can still be uploaded separately if required.
## Core
- Adds an SiteIconManager module which manages automatic resizing and fallback
- Icons are looked up in the OptimizedImage table at runtime, and then cached in Redis. If the resized version is missing for some reason, then most icons will fall back to the original files. Some icons (e.g. PWA Manifest) will return `nil` (because an incorrectly sized icon is worse than a missing icon).
- `SiteSetting.site_large_icon_url` will return the optimized version, including any fallback. `SiteSetting.large_icon` continues to return the upload object. This means that (almost) no changes are required in core/plugins to support this new system.
- Icons are resized whenever a relevant site setting is changed, and during post-deploy migrations
## Wizard
- Allows `requiresRefresh` wizard steps to reload data via AJAX instead of a full page reload
- Add placeholders to the **icons** step of the wizard, which automatically update from the "Square Logo"
- Various copy updates to support the changes
- Remove the "upload-time" resizing for `large_icon`. This is no longer required.
## Site Settings UX
- Move logo/icon settings under a new "Branding" tab
- Various copy changes to support the changes
- Adds placeholder support to the `image-uploader` component
- Automatically reloads site settings after saving. This allows setting placeholders to change based on changes to other settings
- Upload site settings will be assigned a placeholder if SiteIconManager `responds_to?` an icon of the same name
## Dashboard Warnings
- Remove PWA icon and PWA title warnings. Both are now handled automatically.
## Bonus
- Updated the sketch logos to use @awesomerobot's new high-res designs
`/new-topic` redirects back to `/latest`, so the ember router considers this to be a 'refresh'. This triggers the `resetParams()` logic, which would cause the transition to abort, and the composer would never open.
This commit fixes the `resetParams()` logic so that it uses the default values, instead of setting everything to `null`. Therefore the transition is no longer aborted, and the composer opens successfully.
Unfortunately I have not been able to reproduce the issue in a QUnit test.
Previously, when existing composer, the `#main-outlet` element padding was set to zero. This inline style would override any CSS set for that element, causing issues with the mobile footer nav.
The fix removes the inline padding style instead of setting it to zero. It also uses integers for the set values, and removes a duplicate style.
This is a first step of a performance optimisation, more will follow
Previously we did not properly account for previously read topics while
"rushing" marking times on posts.
The new mechanism now avoids "rushing" sending timings to server if all
the posts were read.
Also to alleviate some server load we only "ping" the server with old timings
once a minute (it used to be every 20 seconds)
- moves footer nav to the header on iPads
- disables scrolling events for iPads
- removes footer nav entirely on Chrome PWAs
- toggles DiscourseHub iOS app status bar styling (dark/light) when opening/closing lightboxes and modals
Since enabling pinch-to-zoom in iOS (eae22548de), there was an issue with inputs: Safari auto-zooms inputs with font-size under 16px. Now zooming will be disabled while focus is on an input.
This commit also removes a) a lightbox zoom-enabling event (no longer needed) and b) a comment about iOS zoom issues.
* UX: Render wizard previews for high-DPI displays
Sets up a canvas element of twice the required dimensions, scales all coordinates by 2x, then shrinks the display in css.
* Use window.devicePixelRatio to determine scale factor
Theme developers can include any number of scss files within the /scss/ directory of a theme. These can then be imported from the main common/desktop/mobile scss.
* FIX: correctly retrieve 'login required' setting value on wizard
FEATURE: extract 'invite only' setting in a separate checkbox control
* Update invite_only checkbox locale on wizard.
Co-Authored-By: techAPJ <arpit@techapj.com>
In certain situations the detection method fails. For example, it fails
for a topic containing: a long post (~1600px height), gap, small action
(focus on this), hidden reply.
Previously removing a banner raised a null "banner" in the message bus
channel.
Then Ember.Object.create would fail cause it always expects an object in
constructor.
- Plugin developers using OpenID2.0 should migrate to OAuth2 or OIDC. OpenID2.0 APIs will be removed in v2.4.0
- For sites requiring Yahoo login, it can be implemented using the OpenID Connect plugin: https://meta.discourse.org/t/103632
For more information, see https://meta.discourse.org/t/113249
In certain edge cases, the message bus won't send the message to the
user about the updated review count and it can go out of sync.
This patch synchronizes the review count every time:
1. The user visits the "Needs Review" page
2. Every time the user performs an action
A new checkbox has been added to the Tags tab of the category settings modal
which is used when some tags and/or tag groups are restricted to the category,
and all other unrestricted tags should also be allowed.
Default is the same as the previous behaviour: only allow the specified set of
tags and tag groups in the category.
Such links might be in present in old PMs. For example, a notification of
outstanding flags.
New PMs should receive the correct link but this prevents 404s in the
other case.
"Rejecting" a user in the queue is equivalent to deleting them, which
would then making it impossible to review rejected users. Now we store
information about the user in the payload so if they are deleted things
still display in the Rejected view.
Secondly, if a user is destroyed outside of the review queue, it will
now automatically "Reject" that queue item.
User cards triggered in header were incorrectly positioned in Safari desktop.
Using `position()` instead of `offset()` is more consistent, since header is a fixed element in this scenario.
Handle the case of https://github.com/discourse/DiscoTOC doing this kind of setup:
```
return {
action: "insertDtoc",
icon: "align-left",
label: themePrefix("insert_table_of_contents"),
condition: !composerController.get("model.canCategorize")
};
```
In this case there's no function to call, it's already set.
On smaller mobile devices, the height of the advanced search filters takes up
the whole real estate that it requires the user to scroll down
significantly in order to view the results.
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.
* Revert "FIX: discourse client should know about Logster (#7232)"
This reverts commit bfcbc4d2d6.
* FIX: discourse client should know about Logster (simpler approach)
* 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
## 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
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 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.
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
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 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
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.
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
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.
- 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
Treating TIFF and BMP as images cause us to add them to IMG tags, this is very inconsistent across browsers.
You can still upload these files they will simply not be displayed in IMG tags.
Fixes composer warnings when: a) mentioning groups ("By mentioning @group, you are about to notify x people...") and b) mentioning users in a PM ("You mentioned @user but they won`t be notified...")
Ember3 is more picky about having a container being destroyed and it's easier to cause exceptions, especially in tests.
This fix has been initially created for an exception occuring in tests when running discourse-code-review and discourse-polls tests at the same time. `getCurrentUser` method body was failing as the container was destroyed.
Original stacktrace:
```
"Error: Assertion Failed: expected container not to be destroyed
at new EmberError (ember:2929:31)
at assert (ember:1793:23)
at Container.lookup (ember:17736:64)
at PluginApi.getCurrentUser (discourse/lib/plugin-api:56:31)
at allowUser (javascripts/discourse/initializers/init-code-review:38:29)
at eval (javascripts/discourse/initializers/init-code-review:78:11)
at eval (select-kit/mixins/plugin-api:86:19)
at Array.forEach (<anonymous>)
at eval (select-kit/mixins/plugin-api:85:44)
at Array.forEach (<anonymous>)"
```
Somehow a plugin or some new Chrome bug is causing its heuristic to detect
our textarea for the composer as a target for address autocomplete
This is likely a chrome bug but this change is very safe regardless.
New `about.json` fields (all optional):
- `authors`: An arbitrary string describing the theme authors
- `theme_version`: An arbitrary string describing the theme version
- `minimum_discourse_version`: Theme will be auto-disabled for lower versions. Must be a valid version descriptor.
- `maximum_discourse_version`: Theme will be auto-disabled for lower versions. Must be a valid version descriptor.
A localized description for a theme can be provided in the language files under the `theme_metadata.description` key
The admin UI has been re-arranged to display this new information, and give more prominence to the remote theme options.
When showing a lazy-loaded image, copy the `srcset` property only when
it is actually set. `copyImg.srcset = copyImg.srcset` is not actually a
noop but creates an empty `srcset`, changing content security rules on
the image.
We had Prettier pinned because of https://github.com/prettier/prettier/issues/5529. Since that bug is fixed, unpinning.
Prettier now supports YAML, so this applies Prettier to all .yml except for translations, which should not be edited directly anyway.
- Themes can supply translation files in a format like `/locales/{locale}.yml`. These files should be valid YAML, with a single top level key equal to the locale being defined. For now these can only be defined using the `discourse_theme` CLI, importing a `.tar.gz`, or from a GIT repository.
- Fallback is handled on a global level (if the locale is not defined in the theme), as well as on individual keys (if some keys are missing from the selected interface language).
- Administrators can override individual keys on a per-theme basis in the /admin/customize/themes user interface.
- Theme developers should access defined translations using the new theme prefix variables:
JavaScript: `I18n.t(themePrefix("my_translation_key"))`
Handlebars: `{{theme-i18n "my_translation_key"}}` or `{{i18n (theme-prefix "my_translation_key")}}`
- To design for backwards compatibility, theme developers can check for the presence of the `themePrefix` variable in JavaScript
- As part of this, the old `{{themeSetting.setting_name}}` syntax is deprecated in favour of `{{theme-setting "setting_name"}}`
This commit moves the temporary image to be adjacent to the original image in the DOM. Previously the temporary image was appended to the parent element. Normally this makes no difference because the temporary element has position:absolute. However, if the `:last-child` selector is being used on the parent, it can cause layout changes during loading.
The locale key had to be renamed, because this key is also used as CSS class.
The "invisible" CSS class makes the icon invisible. "unlisted" doesn't have that effect.
Regression following the ember3 upgrade. In addition to fixing, this commit consolidates our social registration logic into one place, and adds tests for the behaviour.
Kris
Maja Komel
Joffrey JAFFEUX
Régis Hanol
Robin Ward
Penar Musaraj
Gerhard Schlager
Bianca Nenciu
Dan Ungureanu
Arpit Jalan
Guo Xiang Tan
David Taylor
Bianca Nenciu
Roman Rizzi
Sam Saffron
Vinoth Kannan
Tim Lange
Neil Lalonde
Tim Lange
Tarek Khalil
Joe
Dannii Willis
Angus McLeod
Joe
Guo Xiang Tan
tshenry
Osama Sayegh
Vinoth Kannan
Rafael dos Santos Silva
Simon Cossar
Jeff Atwood
Erick Guan
Jeff Wong
peterlamber
Daniel
