-
Notifications
You must be signed in to change notification settings - Fork 33
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
Conversation
…o/citizenlab into TAN-928-wrong-author-copy
|
end | ||
def each_schema_with_locale(schema_multiloc) | ||
schema_multiloc.each do |locale, schema| | ||
I18n.with_locale(locale) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the fix.
… schemas at end (to avoid locale switching issues)
@@ -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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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? 🤔
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?) |
There was a problem hiding this comment.
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? 🤔
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok gotchya, thank you! :)
There was a problem hiding this 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 :)
@amanda-anderson Sounds good! I did some manual testing, but it makes sense to run the E2E tests. Thanks for the review! |
The issue is that the author and budget labels are always shown in English and is related to this code in
UiSchemaGeneratorService
andInputUiSchemaGeneratorService
: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:
Changelog
Fixed