DTP (Test > Production: 342f056a) by nicklathe · Pull Request #51465 · code-dot-org/code-dot-org

nicklathe · 2023-04-21T20:19:25Z

No description provided.

In preparation for an update to FactoryBot 5, which fixes some unintuitive behavior when `build`ing objects with descendents. Specifically, the `:pd_teacher_application` factory calls `build :pd_teacher_application_hash_common` which in turn calls `association :school`; right now, even though the Hash is being called with `build` rather than `create`, that `School` object still gets persisted. In fact, that behavior is *required* since we pass the `id` of the `School` object upstream to the `:pd_teacher_application` factory which as part of its own persistence logic expects its `school_id` attribute to reference a persisted object. Startingin FactoryBot 5, the default association strategy will now be inherited from the parent factory, so `build`ing a hash will `build` but not persist the associated `School` object. In most cases this is probably desirable, but here we are relying on the old strange behavior and so now need to explicitly specify that we always want to persist the associated `School` object. https://github.com/thoughtbot/factory_bot/blob/main/GETTING_STARTED.md#build-strategies-1

We expect emails to be globally unique, but the method we currently use to generate test emails for facilitators and workshop organizers means that multiple calls to `build :workshop_organizer` will result in the same email being generated for each user, which will cause an error if we attempt to persist both of them. This isn't a problem right now, because some unexpected behavior in FactoryBot v4 means that record are often automatically persisted upon creation. Starting in v5, we are much more likely to encounter this edge case, so in anticipation of updating to that version we change the generation logic to use unique emails rather than attempting to enforce an arbitrary sequence.

…s to be persisted

…so that its associated records are also persisted and able to be validated

This used to be an overridable method in Devise, but has long since been deprecated, first in favor of `devise_error_messages!` and then in favor of the `devise/shared/error_messages` partial. Fortunately, we have also long since stopped using it. Also remove some associated i18n strings which are similarly unused. - https://github.com/heartcombo/devise/blob/v4.7.0/app/helpers/devise_helper.rb

In preparation for an update to Ruby 3.0; starting in Ruby 2.7.7, Ruby by default targets version 0.3.5 of the `cgi` gem, which fixed a security issue but also made the domain validation more restrictive than necessary. Version 0.3.6 loosens the restrictions. - https://github.com/ruby/cgi/releases/tag/v0.3.6 - ruby/cgi#29 - https://johnathan.org/ruby-2-7-7-invalid-domain/ Without this change, we get several hundred `ArgumentError: invalid domain: ".code.org"` errors in Dashboard tests on Ruby 3. With this change, we do not.

…#51356) * show pl banner for en only * geolocation attempt * add logic to show banners internationally or in US only * add showInternationally flag * Remove unneccessary class_variable_set * Rename file to make clear about unknown location * Fix typo * Use Minitest * Move test outside homepage directory * Move json files into fixtures directory * Change json file names --------- Co-authored-by: Meg Crenshaw <meg@code.org>