Bethany Seeger (Sep 10 2025 at 14:01): Bethany Seeger (Sep 10 2025 at 14:01):Hello,
We are working with someone who is testing out a migration into our test server. We enabled a few of the blocks and are noticing that a new field is showing up in one of them: Geospatial Metadata. He is using the "doNotValidate" flag -- could that cause this new field creation? (he does have super user admin perms)
I'm guessing theres a bug in the consultant's code, as the field Other should really be in the Geographics Coverage -> Other field. Could the "doNotValidate" be creating this "Other" field? If not, what would cause this field to be created?
We have not modified the block at all.
Thanks!
Bethany
Philip Durbin 🚀 (Sep 10 2025 at 14:04):I'm pretty sure that even if the block (geospatial in this case) is not enabled for the collection one can still populate the block's fields (I see "Other" and "Geographical Unit").
I'd take a look at the JSON being used to create this dataset. Do you see those two geospatial fields in there?
Bethany Seeger (Sep 10 2025 at 14:10):Sorry to not be clear -- we did have it enabled first. It's just that, in our setup now, there's an "Other" field that's part of the compound group and then there's another "Other" field that's disconnected from that. There are not two "Other" fields in the actual block.
It looks like our consultant was able to add a field that wasn't there via adding a record. I didn't realize that was possible. But I'm also still troubleshooting what's going on.
He started testing on our 5.14 server and on our 6.6 server -- both places magically have this new field.
I'll get a sample of his JSON.
Thanks!
Philip Durbin 🚀 (Sep 10 2025 at 14:18):Oh, I now see how there are two "Other" fields in your screenshot of the geospatial block, one as part of geographic coverage and one on its own. Hmm.
For reference, here's how the geographic block looks on demo, with only one "Other" field (under geographic coverage):
Screenshot 2025-09-10 at 10.16.45 AM.png
Bethany Seeger (Sep 10 2025 at 14:22):Yeah, that's what helped me realize there was an issue. Is this a side effect of using the "doNotValidate" flag? That new fields could be accidentally created?
Philip Durbin 🚀 (Sep 10 2025 at 14:22):I have this note to myself: "can create publicationIDURL even thought it isn't valid". I discovered (or rediscovered this?) accidentally the other day when writing a test.
Philip Durbin 🚀 (Sep 10 2025 at 14:23):I suspect it's an old bug, that you might be able to create arbitrary fields in Dataverse. If you have a moment to test this, please do!
Bethany Seeger (Sep 10 2025 at 14:23)::-) Sounds like we are in the same boat. If I have a chance I'll test it out.
Philip Durbin 🚀 (Sep 10 2025 at 14:24):If you can create a weird field, please open an issue!
Bethany Seeger (Sep 10 2025 at 15:18):https://github.com/IQSS/dataverse/issues/11809
It appears to only happen when you use a subfield outside of it's compound field setup.
Philip Durbin 🚀 (Sep 10 2025 at 15:23):Yikes! Thanks! :sweat_smile:
Philip Durbin 🚀 (Sep 10 2025 at 15:28):Did you include the JSON for this one?
It's this, right?
{
"typeName": "authorName",
"multiple": false,
"typeClass": "primitive",
"value": "This is a fun and new field, I just made it up!"
},
You're adding authorName, which is normally a subfield of author, as a higher-level field, at the same level as author, title, etc.
Bethany Seeger (Sep 10 2025 at 15:29):That should work to demonstrate the issue
-- I could include the full JSON, if that's helpful.
Bethany Seeger (Sep 10 2025 at 15:30):It basically seems to happen when you use a field in a different spot (like outside of it's compound field). I have not tried the reverse, of using a name from a non-compund field w/i a compound.
Bethany Seeger (Sep 10 2025 at 15:32):Okay, just tried that and it failed:
{"status":"ERROR","message":"Error parsing Json: field title is not a child of author"}
Yes, if you'd update the issue description and attach the full JSON, I'd appreciate it!
Last updated: Oct 30 2025 at 06:21 UTC