When using the login confirmation screen, the referrer URL is `/auth/{provider}`. That means that the user is redirected back to the confirmation screen after logging in, even though login was successful. This is very confusing. Instead, they should be redirected to the homepage.
This can be used for themes/plugins to specify additional URL parameters to be used when starting authentication. Example usage:
```
LoginMethod.findAll()[0].doLogin({params: {mydata: "myvalue"}});
```
Using the rails `form_tag` helper generates a form with the action attribute set to the current URL (without parameters). In this case, we want to include any GET parameters, so it is better to exclude the action attribute from the form tag, and allow browsers to submit to the current URL.
* Make scrolling to bottom post in topic more consistent
* when using the slider to scroll past the bottom post,
we now scroll to the bottom of the post/page IF the
post height is > the window height (e.g. really long
posts). if the post height is smaller, then we lock
onto and jump to the top of the post
* this also removes the mobile hack that would always jump
to the top of the last post on mobile
* Prettier lint
We pick the first topic with 30 responses as our bench topic.
Previously we simply picked the last topic, but hand no guarantee on ordering.
This also attempts to correct previous runs of the bench.
* Reapply "Rename 'target usernames' with 'target recipients' in Composer"
This reverts commit 9fe11d0fc3 which
reverted ebb288dc2c.
* DEV: Add test for replying to PM
The QUnit rake task starts a server in test mode. We need a tweak to allow dynamic CSP hostnames in test mode. This tweak is already present in development mode.
To allow CSP to work, the browser host/port must match what the server sees. Therefore we need to disable the enforce_hostname middleware in test mode. To keep rspec and production as similar as possible, we skip enforce_hostname using an environment variable.
Also move the qunit rake task to use unicorn, for consistency with development and production.
I was playing with groups locally and saw this line. I suspect this method isn't needed at all because I don't see any reference to it anywhere in the code, and as far as I know ActiveRecord objects don't have an `id!` method so if this method is called dynamically somewhere it's most likely failing.
if SiteSetting.secure_media is disabled we still want to
redirect to the signed url for uploads that are marked as
secure because their ACLs are probably still private
* Add a rake task to disable secure media. This sets all uploads to `secure: false`, changes the upload ACL to public, and rebakes all the posts using the uploads to make sure they point to the correct URLs. This is in a transaction for each upload with the upload being updated the last step, so if the task fails it can be resumed.
* Also allow viewing media via the secure url if secure media is disabled, redirecting to the normal CDN url, because otherwise media links will be broken while we go and rebake all the posts + update ACLs
* DEV: Remove buffered rendering from topic-list-item
This is another refactoring in the multi-step process to remove all uses
of our custom Render Buffer.
Previous commit: 1c7305c0f1 in this
series.
This is just a refactor and should not change any functionality.
* apply prettier fix
* update syntax
* Use computed properties where possible
* switch to using didReceiveAttrs
* Simplify topic.pinned observer
43ddf60cdf introduced a new method for dismissing new topics in topic-tracking-state, which works on a per-category basis.
This commit removes the old mechanism, which was to delete all 'new' topics from the local tracking state, regardless of category.
6e1fe22 introduced the possiblity for category_users to have a NULL notification_level, so that we can store `last_seen_at` dates without locking the notification level. At the time, this did not affect the topic-tracking-state query. However, the query changes in f434de2 introduced a slight change in behavior.
Previously, a subquery would look for a category_user with notification_level=mute. f434de2 refactored this to remove the subquery, and inverted some of the logic to suit.
The new query checked for `notification_level <> :muted`. If `notification_level` is NULL, this comparison will return NULL. In this scenario, notification_level=NULL means that we should fall back to the default tracking level (regular), and so we want the expression to resolve as true, not false. There was already a check for the existence of the category_users row, but it did not check for the existence of a NOT NULL notification_level.
This commit amends the expression so that the notification_level will only be compared if it is non-null.
* FIX: bulk insert to create application requests
* FIX: bulk insert to create topics
* FIX: no need to create separate user for each topic, post etc.
* FIX: Another bulk_insert of ApplicationRequests
* FIX: dont create user and topic instances when not neccessary
* FIX: merge examples with expensive setup into one example
