When calculating whether the attached uploads went over the SiteSetting.email_total_attachment_size_limit_kb.kilobytes limit, we were using the original_upload for the calculation instead of the actually attached_upload, which will be smaller in most cases because it can be an optimized image.
At the moment, when filtering by group, the directory will unconditionally return the current user at the top of the list. This is quite unexpected, given that the user is deliberately trying to filter the list. This commit makes sure the 'include current user' logic only triggers for unfiltered directories
This adds a new min_trust_level_to_allow_ignore site setting that enables admins to control the point at which a user is allowed to ignore other users.
After the search term is parsed for advanced search filters, the term may
become empty. Later, the same term will be passed to Discourse.route_for
which will raise an ArgumentError.
> URI(nil)
ArgumentError: bad argument (expected URI object or URI string)
Partial revert of b143412be4 (the refactoring is not reverted)
This broke a few things, so we need to investigate and make some changes before reinstating the error
Hopefully this will prevent fellow developers from spending a morning
trying to figure out why the jobs that are run after a post is created
are not finding the post in the database.
That's because if you're inside a transaction when creating a post, the jobs
will likely run before the transaction is being commited to the database.
There was a "warning" in the comments of the PostCreator class but raising an
exception should hopefully help catch those issue much faster :fingers_crossed:.
This is hard to test since all the tests are run in a transaction...
This will only happen if the user_associated_accounts table is currently empty. It's useful for people that may be depending on primary key values in data explorer queries. This change will only have an effect on sites which have not already run this migration.
* FEATURE: display error if Oneboxing fails due to HTTP error
- display warning if onebox URL is unresolvable
- display warning if attributes are missing
* FEATURE: Use new Instagram oEmbed endpoint if access token is configured
Instagram requires an Access Token to access their oEmbed endpoint. The requirements (from https://developers.facebook.com/docs/instagram/oembed/) are as follows:
- a Facebook Developer account, which you can create at developers.facebook.com
- a registered Facebook app
- the oEmbed Product added to the app
- an Access Token
- The Facebook app must be in Live Mode
The generated Access Token, once added to SiteSetting.facebook_app_access_token, will be passed to onebox. Onebox can then use this token to access the oEmbed endpoint to generate a onebox for Instagram.
* DEV: update user agent string
* DEV: don’t do HEAD requests against news.yahoo.com
* DEV: Bump onebox version from 2.1.5 to 2.1.6
* DEV: Avoid re-reading templates
* DEV: Tweaks to onebox mustache templates
* DEV: simplified error message for missing onebox data
* Apply suggestions from code review
Co-authored-by: Gerhard Schlager <mail@gerhard-schlager.at>
`setPermissionsGroups` would initialize an empty permissions object whenever new groups were added to the Tag Group. This meant that if you selected the `visible` permission and then added groups to the Tag Group, the `visible` permission would be obliterated and the Tag Group would be treated as though it was `private`.
This reverts commit f31de2fa20.
This is causing `NoMethodError (undefined method `bytesize' for nil:NilClass)` in the anonymous cache. More investigation required
This moves the library into our lib folder, and refactored it to more
modern Javascript. I've kept the MIT license at the top of the file.
Doing this allows us to import it as a library in Ember CLI and ditch
yet another global variable.
CSS are blocking resources, so keeping them below JS delays
rendering of the page. CSS should be loaded ASAP.
This change speeds up first contentful paint by 0.2s on localhost.
The slower the device, the bigger the difference could be.
ListableTopicSerializer includes many attributes which we are not using, and is likely to cause N+1s when not used in conjunction with TopicQuery.
Using the BasicTopicSerializer means that no other tables are required.
