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

Changing decimal place restrictions results in incorrect values persisted to DB #522

Open
jordan-ghost opened this issue May 30, 2023 · 0 comments

Comments

@jordan-ghost
Copy link

jordan-ghost commented May 30, 2023

Describe the bug

After having a Supertable field set to 'Number' type with 'Decimal Points' set to zero, and some content saved into that field on some entries, we updated the 'Decimal Points' option to 1. In the editor, the values shows formatted with 1 decimal place, but when saving a new value, it is truncated to an integer.

Example: On the Entry editor page for an Entry which uses this Supertable

  1. Displayed value: 256.0
  2. Change value to 512.5
  3. Save entry
  4. Reload entry editor page
  5. Displayed value: 512.0

Additionally, the GraphQL API delivers this field's value as an integer.

Expected: displayed value would be 512.5 (actual 512.0)
Expected: value provided via API would be 512.5 (actual 512)

Steps to reproduce

  1. Create a Supertable and give it a field of type Number
  2. Set the field's 'Decimal Points' option to 0
  3. Create a Section and Entry Type that uses this Supertable
  4. Create an Entry of the new type and enter a value into the Number field
  5. Save this Entry
  6. Modify the Supertable field by setting Decimal Points to a non-zero value (tested: 1, 3)
  7. On the saved Entry, change the value of the Number field to a non-integer value
  8. Save the Entry again
  9. Revisit the Entry's editor page.

Expect: Field value to be non-integer and equal to the saved value
Actual: Field value is truncated to integer of the saved value

Craft CMS version

4.4.6.1

Plugin version

3.0.81

Multi-site?

No

Additional context

  • This issue does not occur when the field is created with a non-zero number of decimal points from the beginning.

  • Not tested: Creating field with no decimal points and then updating it to non-zero decimal points without saving a value against it on an Entry in between.

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

No branches or pull requests

1 participant