v1.2.0beta9 has introduced a regression in edit of a private topic
(first post). Previously a check for no change in TopicsController was
made but it has been changed without considering that the topic could
be private.
By simply forcing a conversion of `topic.category_id` to integer, the case
where its value is nil is handled correctly as it was previously.
If a site setting has `shadowed_by_global: true` then, if
a `GlobalSetting` exists with the same name then that value
will be used instead. Additionally, the setting will be hidden.
This is useful in a multisite environment for private settings
such as API keys. You want to set it globally, yet not display
the key to customers.
If force_avatar_update is passed in sso attributes it errors on
force_avatar_update.to_i. The SingleSignOn class forces avatar_force_update
to a boolean, so it should be treated as such.
FIX: Don't require login to view post raw
FIX: Don't submit read-guidelines for anonymous users (causes
unnecessary 403 errors from ensure_logged_in)
FIX: Don't pass nil to an array serializer
- FIX: make sure we set a default name to a pasted image only on Chrome (the only browser that supports it)
- FIX: use ".json" extension to uploads endpoints since IE9 doesn't pass the correct header
- FIX: pass the CSRF token in a query parameter since IE9 doesn't pass it in the headers
- FIX: display error messages comming from the server when there is one over the default error message
- FIX: HACK around IE9 security issue when clicking a file input via JavaScript (use a label and set `visibility:hidden` on the input)
- FIX: hide the "cancel" upload on IE9 since it's not supported
- FIX: return "text/plain" content-type when uploading a file for IE9 in order to prevent it from displaying the save dialog
- FIX: check the maximum file size on the server 💥
- update jQuery File Upload Plugin to v. 5.42.2
- update JQuery IFram Transport Plugin to v. 1.8.5
- update jQuery UI Widget to v. 1.11.1
If a user has a current avatar, and sso_overrides_avatar is true, but no avatar_url is
passed in the sso attributes, the current code errors, as it tries to parse a nil
as a URL. It seems to me valid that a third party system may not pass an avatar_url in
some cases (e.g. avatars may not be mandatory, so not all users may have them)
This might warrant a discussion about what should happen in this case; maybe the current
avatar in discourse should be removed? This branch merely stops the login process erroring.
