Since commit 23682fadd8, we have had the comment:
> # Review
> # Doble check why the file is stored with a name different to empty.pdf
This might be outdated.
These expectations are already covered by attach_new_file, so they are no longer needed:
> expect(page).to have_css ".loading-bar.complete"
We can remove the tests:
> "Should update loading bar style after invalid file upload"
because the expectation:
> expect(page).to have_css ".loading-bar.errors"
It is already tested in "Should not update document cached_attachment field after invalid file upload"
Note that this commit also applies a similar change to the
imageable_attach_new_file method by removing an unnecessary variable.
In order to testing with more than 1 max documents allowed we
keep one test with this value.
Removed the now-unused 'documentable_fill_new_valid_proposal' method
from common actions.
Note that it does not seem necessary to create an administrator with the user, as was
done in the original shared example. Also, as in the previous commit, it appears that
we do not need to set the user as the author when creating the documentable.
Also removed the documentable_redirected_to_resource_show_or_navigate_to method,
which was only used for the :proposal factory but was not necessary.
- In the "Proposal new" case (this commit), after submitting the form we are
redirected to the "created" page, where the link "Not now, go to my proposal"
does not appear. This caused the method to always raise a
Capybara::ElementNotFound and return nil.
Instead, this "created" page already displays a preview of the proposal
and a link to publish it. Since we can verify that the proposal was created
successfully here, no redirection or click is needed.
- In the "Proposal edit" case (next commit), the user is redirected directly
to the proposal's "show" page after update, so again, the method is
unnecessary and has been removed.
Replaced 'login_as' with 'do_login_for' using 'management: management_section?' to
handle login requirements correctly for each context.
Also removed the now-unused 'documentable_fill_new_valid_budget_investment' helper
from common actions.
Note that it does not seem necessary to create an administrator with the user, as was
done in the original shared example. Also, as in the previous commit, it appears that
we do not need to set the user as the author when creating the documentable.
While reviewing this, we also noticed that the create(:administrator, user: user) call
was unnecessarily included in the nested_imageable system spec in commit cdfaec5217 when
the path is a management section. So we use this commit to remove the unnecessary condition.
Make 'path', 'submit_button_text' and 'notice_text' dynamic based on
the factory.
Also adjusted the user. Budget investments require a level 2 user but do not need to be
an administrator.
Copied and renamed the 'documentable_fill_new_valid_budget_investment' method from
common actions, and introduced a 'fill_in_required_fields' method to manage multiple factories.
Added the two tests that were conditionally skipped in the shared example using
'unless: documentable_factory_name == "dashboard_action"', but omitted the call to
'documentable_redirected_to_resource_show_or_navigate_to', since it only applies to
proposals.
Note that when we create the documentable seems do not need use the user as author.
Removed 'documentable_path_arguments' and 'management'
parameters because they are not used by dashboard_action.
Also moved and renamed the 'documentable_fill_new_valid_dashboard_action' method
from the common actions helper to this file, since it is now only used here.
Hardcoded 'path', 'submit_button_text', and 'notice_text' for dashboard_action.
These remain fixed for now until dynamic values are required in future commits.
The "foundation_rails_helper" gem is no longer maintained and is
incompatible with Rails 7.1. To avoid blocking the upgrade, we've vendored
the vendor/foundation_rails_helper/form_builder.rb as a copy of the
original FormBuilder class.
To mantain compatibility with auto_labels and button_class variables, that
are used in the original builder, we are overwriting in the foundation
form builder initializer.
The gem has been removed from the Gemfile and replaced with this vendored
fallback. This workaround is safe to remove once legacy Foundation CSS
support is dropped.
All vendored code retains the original MIT license and attribution.
ros-apartment 3.0.0+ includes official support for connection handling in Rails 7,
so we no longer need to override `ActiveRecord::ConnectionHandling#connected_to`.
References: PR #194 and #243 in ros-apartment
We were using a placeholder, which is way less accessible than a label.
One issue here (which also happened before, but is now more obvious) is
that, when adding several options, there will be many fields with the
same label.
Another issue is that, for some languages, we're using texts like "Add a
closed answer", which might be confusing because we might be editing an
existing answer. The proper solution would probably be using the text
"Option 1", "Option 2", ... I'm not doing so right now because I'm not
sure that's a good option and because changing the text would mean
losing the existing translations.
This way the fields are easier to use, and we can get rid of the
placeholders.
Note we're simplifying the `answer_result_value` in order to make it
easier to return `0` instead of `nil` when the field is empty.
Also note there's a small change of behavior here; previously, these
fields were empty by default, and now their value is `0` by default, so
blindly clicking the "Save" button would send `0` instead of an empty
value. I don't think it's a big deal, though, but we need to keep that
in mind.
Back when we added all the missing labels (changes that we merged in
commit c34cab282), we forgot about fields which had placeholdes, since
Axe doesn't report an error when there are placeholders but there aren't
labels.
In this case, we were using an invalid <label> tag for the question
options, and <h3> tags as labels for the votes.
Using standard labels solves the issue.
Saying that we're supposed to introduce a descriptive title in a field
labelled as "Title" is redundant. Besides, the text of the placeholder
was barely distinguishable, making it harder to fill in the form.
