These specs are inherently fragile when they are run in a concurrent mode
in CI.
One process will create an upload, another will destroy the upload on disk
at the same time. We need a new safe mechanism here.
Previously we were always hard-coding expiry, this allows the secure session
to correctly handle custom expiry times
Also adds a ttl method for looking up time to live
Previous versions of the mail-receiver used query based api credentials,
if we detect this we will show a message in the admin panel to update
the mail receiver.
POSIX's `head` specification states: "The application shall ensure that the number option-argument is a positive decimal integer"
Negative values are supported on GNU `head`, so this works in the discourse docker image. However, in some environments (e.g. macOS), the system `head` version fails with a negative `n` parameter.
This commit does two things:
Checks the status at each stage of the pipe, so it cannot fail silently
Flip the `ls` command to list in descending time order, and use `tail -n +501` instead of `head -n -500`.
The visible result is that macOS users no longer see head: illegal line count -- -500 printed throughout the test suite.
When starting autospec, it says
> Press [ENTER] to stop the current run
However, [ENTER] does nothing unless a spec has failed. Sometimes I want to abort anyway, so that the run is restarted.
I want to use autospec while working on a single spec file. At the moment, it will start running all specs once it completes the file I'm working on. With parallel mode enabled, this causes CPU usage to spike dramatically, affecting IDE performance, battery life, and fan noise. I would prefer that it only runs all specs when I explicitly press [ENTER]
This commit adds a new ENV variable `AUTO_RUN_ALL`. To prevent auto-running all specs, set it to 0. The default behavior remains unchanged.
* Fix user title logic when badge name customized
* Fix an issue where a user's title was not considered a badge granted title when the user used a badge for their title and the badge name was customized. this affected the effectiveness of revoke_ungranted_titles! which only operates on badge_granted_titles.
* When a user's title is set now it is considered a badge_granted_title if the badge name OR the badge custom name from TranslationOverride is the same as the title
* When a user's badge is revoked we now also revoke their title if the user's title matches the badge name OR the badge custom name from TranslationOverride
* Add a user history log when the title is revoked to remove confusion about why titles are revoked
* Add granted_title_badge_id to user_profile, now when we set badge_granted_title on a user profile when updating a user's title based on a badge, we also remember which badge matched the title
* When badge name (or custom text) changes update titles of users in a background job
* When the name of a badge changes, or in the case of system badges when their custom translation text changes, then we need to update the title of all corresponding users who have a badge_granted_title and matching granted_title_badge_id. In the case of system badges we need to first get the proper badge ID based on the translation key e.g. badges.regular.name
* Add migration to backfill all granted_title_badge_ids for both normal badge name titles and titles using custom badge text.
* If a staff user created only a security key as their single 2FA option. they continued to be prompted to create a 2FA option because we only considered this condition satisfied if a TOTP was added.
* The condition is now satisfied if TOTP OR security keys are enabled.
Robin Ward
Daniel Waterworth
Dan Ungureanu
Simon Cossar
Mark VanLandingham
Gerhard Schlager
Vinoth Kannan
Sam Saffron
Blake Erickson
Jay Pfaffman
Mark VanLandingham
David Taylor
Roman Rizzi
Martin Brennan