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

🗑️ [#3283] Make FormDefinitionSerializer.name read only #4829

Merged
merged 1 commit into from
Dec 6, 2024

Conversation

stevenbal
Copy link
Contributor

@stevenbal stevenbal commented Nov 18, 2024

Related to #3283

Changes

  • Make FormDefinitionSerializer.name read only

Checklist

Check off the items that are completed or not relevant.

  • Impact on features

    • Checked copying a form
    • Checked import/export of a form
    • Config checks in the configuration overview admin page
    • Problem detection in the admin email digest is handled
  • Release management

    • I have labelled the PR as "needs-backport" accordingly
  • I have updated the translations assets (you do NOT need to provide translations)

    • Ran ./bin/makemessages_js.sh
    • Ran ./bin/compilemessages_js.sh
  • Commit hygiene

    • Commit messages refer to the relevant Github issue
    • Commit messages explain the "why" of change, not the how

@stevenbal stevenbal marked this pull request as draft November 18, 2024 08:52
@stevenbal stevenbal force-pushed the issue/3283-remove-3.0.0-deprecations branch from d621be4 to 35c4c20 Compare November 18, 2024 11:56
@@ -114,8 +114,7 @@ class Meta:
"view_name": "api:formdefinition-detail",
"lookup_field": "uuid",
},
# TODO: enable this in v3, deprecate writing this field
# "name": {"read_only": True}, # writing is done via the `translations` field
"name": {"read_only": True}, # writing is done via the `translations` field
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sergei-maertens do I understand it correctly that this field is currently no longer used for writing? I was wonder whether the import code needs to add the name in translations if it doesn't exist. Or can we assume that imports have these translations already?

Copy link
Member

Choose a reason for hiding this comment

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

indeed - when we added translations we forgot that the 'main' field could also still be written to and that results in writes happening with the currently active locale (so if you have the UI in english, it would write to name_en).

Things didn't break so far because the translations are defined after the name field, so those overwrite the name_en and name_nl fields again, but that was not deliberately and works completely by accident.

You can indeed assume the imports have translations already, and if they don't, well, it's one of the things to mention in the 3.0 release notes and a reason why this was postponed until a major version :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a changelog entry for it

Copy link
Member

Choose a reason for hiding this comment

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

Copy link

codecov bot commented Nov 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.60%. Comparing base (d1513d0) to head (6b4fbed).
Report is 2 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #4829   +/-   ##
=======================================
  Coverage   96.60%   96.60%           
=======================================
  Files         752      752           
  Lines       25809    25809           
  Branches     3411     3411           
=======================================
  Hits        24932    24932           
  Misses        613      613           
  Partials      264      264           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@stevenbal stevenbal force-pushed the issue/3283-remove-3.0.0-deprecations branch from 35c4c20 to cae00db Compare November 18, 2024 12:36
@stevenbal stevenbal marked this pull request as ready for review November 21, 2024 14:51
@stevenbal stevenbal marked this pull request as draft November 21, 2024 14:51
@stevenbal stevenbal force-pushed the issue/3283-remove-3.0.0-deprecations branch from cae00db to 2bd739a Compare December 2, 2024 15:50
@stevenbal stevenbal marked this pull request as ready for review December 2, 2024 15:52
@sergei-maertens sergei-maertens force-pushed the issue/3283-remove-3.0.0-deprecations branch from 2bd739a to 6b4fbed Compare December 6, 2024 07:30
@sergei-maertens sergei-maertens merged commit 26615d1 into master Dec 6, 2024
17 of 18 checks passed
@sergei-maertens sergei-maertens deleted the issue/3283-remove-3.0.0-deprecations branch December 6, 2024 07:31
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.

2 participants