@webflo Done, and sorry about that. I had intended to do another release after fixing the bug and I got sidetracked.
@megachriz Are there any cases where the user would not want the calculation to be performed if the value was NULL? For example, if the field is required, that might be a safe assumption. But if the field is not required, I can imagine that a developer might want to do a calculation that only does something if the field has a numeric value (if it is NULL, don't do the calculation).
Zero is a problem because it could mean "no value" or it could mean "the value is 0"; I have been working on a somewhat related issue in the Field Encrypt module, which uses 0 as a placeholder value for integer fields, but it was been decided to use NULL instead as the placeholder because 0 could represent an important value. ( 📌 We only encrypt fields if they don't match the placeholder value Active )
I haven't thought through all the implications of this, but my initial thought is that this could be a little dangerous.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
Drupal 7.x is now end of life.
The "default includes" feature of JSON:API Extras and this module are currently incompatible, so you cannot put any value in that field and use this module.
Instead, I believe you can just use an ?includes=node.image in the standard way for JSON:API. See the
documentation on includes →
for more info.
Thanks!
I've been using this for about a year on a site which imports about 20 different entities using Tamper, about 10,000 pieces of content, and everything is working great. My code isn't really affected by the changes in #20, so I will not set to RTBC, but I can say that this has made importing a lot easier for me because there are lots of null values that are now handled correctly.
Closed in favor of 📌 Add attributes alongside annotations Postponed
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
This also applies to the release branch, so bumping to critical.
ptmkenny → created an issue.
Unfortunately the MR is broken against HEAD. Setting to "Needs work" so that it can be rebased (needs manual rebase; /rebase in GitLab was not sufficient).
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
ptmkenny → created an issue.
Setting to "Needs work" as the phpunit tests aren't passing.
ptmkenny → created an issue.
ptmkenny → created an issue.
Fixed on 1.0.x. Leaving as "Postponed" because 2.x may need this as well.
This has been merged and Drupal 11 has been released, so I'm closing now.
@ro-no-lo: I think part of the problem here is that the default branch for this module is set to 1.0.0, so merge requests are based off 1.0.0, but the development branch is actually 1.0.x.
A lot of confusion could be eliminated if the development branch was switched to 1.0.x as described here: https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
I'd do it myself but you need ownership permissions for the module to change the default branch, so only you can do that.
Thanks for adding me!
Can this be converted to an MR? That way the tests can be run for additional confirmation.
To run the tests, I created an MR of patch #48.