I feel like the references to review_fields should have been flagging a warning by now. They don't specifically break anything, but they could leave someone (me, just now!) doing a lot of head-scratching about why some defaults weren't doing anything.
It might also be worth referencing the user_review_fields table in release notes in case anyone has legacy table in their system.
Essentially the same as this: https://github.com/eprints/eprints/issues/196
I did spend a while trying to work out why the default value applied to a non-existent field didn't results in an error or warning.
I think I've traced it through to this: https://github.com/eprints/eprints3.4/blob/dfe6a1d7e1e5b84540eef136b3e5390ef2e7596e/perl_lib/EPrints/DataObj.pm#L305-L309 which steps through the fields defined for a dataset, and supplements incoming
$data->{fieldname}with stuff from$defaults->{fieldname}.I feel like the references to
review_fieldsshould have been flagging a warning by now. They don't specifically break anything, but they could leave someone (me, just now!) doing a lot of head-scratching about why some defaults weren't doing anything.It might also be worth referencing the
user_review_fieldstable in release notes in case anyone has legacy table in their system.