I’m trying to send a PATCH to update a log from Node-Red
Never updated a log before.
But I end up with this error:
Not the kind of error I would expect…
msg.payload = {
"data": {
"type": "log-lab_test",
"id": id_log,
"attributes": {
"name": "Jordprøve",
"status": "done"
}
}
}
Not sure about the message, but you need to Get the UUID of the log then include it in the patch, if I remember correctly. I’ll have a look for a patch example.
Isn’t that the id of the log?
as in id:“6b181bea-fa05-40f5-bb16-5cedd66a83fc” of the log?
Yes, sorry…
my bad, brain didn’t process the variable 
processing is for computers, I think 
"log--lab_test"
not
"log-lab_test"
Yep. I know. Used – at first. Same error on both
I guess the error states translations?
is there any field in the API like “translation”:“en”
perhaps something different in your instance because you use translations?
try patching to endpoint /no/log/lab_test?
It could be a bug with translated sites:
might need @mstenta to have a look.
Nothing happens then.
Propably a bug.
Huh…
Been using the same API node all over. Realised I had a farmOS API v2 node.
Should propably do some house-cleaning…
Anyway : The v2 node gives this error when injecting the exact same payload.
TypeError: Cannot read properties of undefined (reading 'hasOwnProperty')
Yea, me too…
Good to know @pat, will take note. The V2 is very much WIP,
@pat have you compared your post to the existing JSON at the API endpoint? to see if anything is translated?
or tried including the appropriate langcode?
msg.payload = {
"data": {
"type": "log-lab_test",
"id": id_log,
"attributes": {
"name": "Jordprøve",
"status": "done"
"langcode": "en"
}
}
}
or
msg.payload = {
"data": {
"type": "log-lab_test",
"id": id_log,
"attributes": {
"name": "Jordprøve",
"status": "done"
"langcode": "no"
}
}
}
Well, we have this one:
"revision_translation_affected": true,
Does’nt seem to make any difference if it’s true or false.
Experimented with all three settings.
"attributes": {
"drupal_internal__id": 1179,
"drupal_internal__revision_id": 948,
"langcode": "en",
"revision_created": "2023-01-11T15:43:52+00:00",
"revision_log_message": null,
"name": "Jordprøve",
"timestamp": "2023-01-11T12:40:51+00:00",
"status": "pending",
"created": "2023-01-11T12:40:51+00:00",
"changed": "2023-01-11T15:43:52+00:00",
"default_langcode": true,
"revision_translation_affected": true,
"data": null,
"notes": null,
"flag": [],
"is_group_assignment": false,
"geometry": null,
"is_movement": false,
"quick": [],
"lab_test_type": "soil",
"lab_received_date": "2023-01-18T00:01:01+00:00",
"lab_processed_date": null
},
Just catching up on this thread… not sure what the cause of the issue is yet (or if it’s a bug or not). I’m new to using Drupal localization/translation features too so we’ll be learning together. 
First thing to note: Drupal has two different “mechanisms” for localization. One is for “interface translations” (eg: all the UI text that comes in the module code), and one for “content translations” (eg: so you can have multiple versions of a record, each in a different language).
farmOS aims to support the former (interface translation), but not the latter (content translation), because we don’t foresee that being a need for most users (if you do need it, you are free to experiment with Drupal’s features yourself and report back), as opposed to cases where Drupal is used for a public-facing website where you want your content to be available to visitors in multiple languages.
The reason I’m outlining that is: from the perspective of API requests, I don’t think you should ever need to touch the langcode attribute or any other language attributes for that matter. The records you create/update via the API are considered “content” and therefore don’t support individual content translations (farmOS does not turn that module on).
I believe that’s why the error message states: “… modify one of the translations that do exist: en” - that is referring to existing languages of the record you are updating. Records (content) will always be the default language of the site, which in the case of farmOS is always en (even if you write your notes/etc in another language).
(There is a technical reason why the default is always en, which you can learn more about here: https://www.drupal.org/project/farm/issues/3257430)
So… back to the issue at hand…
In order to determine if this is a bug or not, I think we need to replicate it in as simple a form as possible, to isolate whether or not it is caused only by the fact that @pat is using the farm_l10n module.
The way I would do this is: create a barebones API request that runs correctly on a non-translated instance, and then run that on @pat’s (or any instance with farm_l10n enabled) and see if the error occurs.
Based on the thread above, I’m not convinced that a “correct” API request was made yet. And I would prefer to see curl commands that are made outside of Node Red just to isolate that as a potential contributing factor.
@pat @Farmer-Ed would you two be able/interested in testing this out in that way together to see if we can get any clues?
Sure, I actually have some of @pats Soil Sample Data in my Dev instance already which has no translations, So I can do that when I get a chance a little later.
Actually had a moment to test now.
The payload worked without errors on an untranslated instance.
I just added a UUID from my instance.
msg.payload = {
"data": {
"type": "log-lab_test",
"id": "03979e6e-e6e6-44a9-8581-5a6ace4eec99",
"attributes": {
"name": "Jordprøve",
"status": "done"
}
}
}
return msg;
Installed the Norwegian Language
and got
@pat try setting your users language to English and try again.
@mstenta Mine works fine in English but not Norwegian, haven’t tried other languages (not sure if that should matter?)
Oh. I’ll try that tonight.
Well, that worked
msg.payload = {
"data": {
"type": "log--lab_test",
"id": uuid,
"attributes": {
"name": "Codetest",
"status": "done"
}
}
}