Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TAN-928 Wrong author copy #7876

Merged
merged 34 commits into from
May 16, 2024
Merged

TAN-928 Wrong author copy #7876

merged 34 commits into from
May 16, 2024

Conversation

sebastienhoorens
Copy link
Contributor

@sebastienhoorens sebastienhoorens commented May 13, 2024

The issue is that the author and budget labels are always shown in English and is related to this code in UiSchemaGeneratorService and InputUiSchemaGeneratorService:

def generate_for(fields)
  locales.index_with do |locale|
    I18n.with_locale(locale) do
      generate_for_current_locale fields
    end
  end
end

The previous code would add the author and budget fields to the generated schemas and thereby skip the I18n.with_locale(locale) part. By adding the author and budget to the fields at the beginning, this issue was solved and the code simplified.

I also did some refactoring:

  • Getting the participation_method inside the schema services felt like a code smell, so the participation_method was passed as a parameter instead.
  • The ideas_spec file was way too long with many inconsistencies and some duplicate examples. Some cleanup was done by splitting up the file. However, the diff for the ideas_spec file remains very unreadable. Apologies for that, I didn't really change anything significant, just started some cleanup before realizing it's better to split up this file.
Screenshot 2024-05-16 at 10 01 37

Changelog

Fixed

  • [TAN-928] The labels of the author and budget fields use the translated copy for the current locale instead of the English copy.

Copy link

@cl-dev-bot
Copy link
Collaborator

cl-dev-bot commented May 13, 2024

Warnings
⚠️ The PR title contains no Jira issue key (case-sensitive)
⚠️ The branch name contains no Jira issue key (case-sensitive)
Messages
📖 Changelog provided 🎉
📖

Run the e2e tests

📖 Check translation progress

Generated by 🚫 dangerJS against 49e4f6b

end
def each_schema_with_locale(schema_multiloc)
schema_multiloc.each do |locale, schema|
I18n.with_locale(locale) do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the fix.

@@ -13,7 +13,7 @@ class WebApi::V1::IdeasController < ApplicationController
def json_forms_schema
input = Idea.find params[:id]
enabled_fields = IdeaCustomFieldsService.new(input.custom_form).enabled_fields
json_attributes = JsonFormsService.new.input_ui_and_json_multiloc_schemas enabled_fields, current_user, input.input_term
json_attributes = JsonFormsService.new.input_ui_and_json_multiloc_schemas enabled_fields, current_user, input.participation_method_on_creation, input.input_term
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The service would extract the participation method from the participation context of the custom form. This is exactly what participation_method_on_creation does.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from the participation context of the custom form

@sebastienhoorens Does this mean that the form object itself stores some information about the type of participation method? Or is this extracting the participation method based on the current phase? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amanda-anderson The custom form is linked to either a project, or a phase (which is still called the participation context, but actually you now always need a phase to participate). This is then passed to participation_method_for in factory.rb. The participation methods are separate classes, that are not persisted in the database.

For custom fields, there are two situations:

  • Ideation: Then the participation context of the custom form is always the project, and when given a project participation_method_for will always create an ideation method
  • Native survey: Then the participation context is always a phase and participation_method_for will create a native survey participation method.

Actually I'm not sure what would happen if an admin created an input in a voting phase (I think this is possible?). I'll take a look at this case to make sure this situation also still works.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah my only thought here was about admins adding inputs (to a specific phase) during other phases in the project :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just tested it, and it still works the same for voting phases :)

context 'when admin' do
before { admin_header_token }

example 'Get the json schema and ui schema for an ideation input with author field', document: false do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the spec that caches the bug.

end
json_schema_multiloc = InputJsonSchemaGeneratorService.new.generate_for visible_fields
ui_schema_multiloc = InputUiSchemaGeneratorService.new(input_term, supports_answer_visible_to).generate_for visible_fields
fields.reject!(&:hidden?)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't completely understand the changes here. Before, were we rejecting fields if they were not enable or hidden? And now we're only rejecting them if they're hidden? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So before, we filtered out these values and assigned the remaining fields to "visible_fields", but we don't need to do that anymore then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed, actually I think this service should never do any filtering on the fields and should only care about generating the corresponding schemas for whichever fields are passed. Then it's the caller's responsibility to pass the right fields. In the end, I added back fields.reject!(&:hidden?) because this is more of an explicit requirement (for inputs, the hidden attribute is only used to hide their fields from the form/schema), but I hope one day we can remove this line.

An alternative could be to pass the custom form, and let the JsonFormsService determine the fields, but that would be less consistent with the registration (user) fields, and I hope that we can unify the code of the schema's for both one day.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok gotchya, thank you! :)

Copy link
Contributor

@amanda-anderson amanda-anderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes make sense to me I think - just had one question about the enabled/hidden change in json_forms_service.rb, but happy to approve in advance.

Should we run the E2E tests for this branch maybe as well just to confirm they're still passing? If you merge in the latest master, the E2E tests should be stable now :)

@sebastienhoorens
Copy link
Contributor Author

Should we run the E2E tests for this branch maybe as well just to confirm they're still passing?

@amanda-anderson Sounds good! I did some manual testing, but it makes sense to run the E2E tests. Thanks for the review!

@sebastienhoorens sebastienhoorens merged commit 9108d83 into master May 16, 2024
9 of 10 checks passed
@sebastienhoorens sebastienhoorens deleted the TAN-928-wrong-author-copy branch May 16, 2024 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants