V8-archive: Field translation sent as string not JSON

[binary-koan]

Bug Report

Steps to Reproduce

1. Create a field with translations via the API, for example:

curl "http://localhost:8080/_/fields/translated_collection" \
  -H "Content-Type: application/json;charset=utf-8" \
  -H "Authorization: Bearer SOMETOKEN" \
  --data '{"sort":null,"field":"translated_field","type":"string","datatype":"VARCHAR","interface":"slug","default_value":null,"options":{"placeholder":"","forceLowercase":true},"readonly":false,"required":false,"unique":false,"note":null,"hidden_detail":false,"hidden_browse":false,"primary_key":false,"validation":null,"length":200,"collection":"comparison_page","translation":{"en-US":"THIS IS TRANSLATED"}}'

(note the "translation":{"en-US":"THIS IS TRANSLATED"} key at the end of the form data)

1. Request all collections (like the app does to hydrate):

curl "http://localhost:8080/_/collections" \
  -H "Authorization: Bearer SOMETOKEN" \
  -H "Content-Type: application/json;charset=utf-8"

Expected Behavior

The translated_collection collection and translated_field field both have a translation property which is an object with an en-US key, something like

"data": [
  {
    "collection": "translated_collection",
    "fields": {
      "translated_field": { ..., "translation": { "en-US": "THIS IS TRANSLATED" } }
    },
    "translation": { "en-US": "TRANSLATED COLLECTION NAME" },
    ...
  }
]

Actual Behavior

The translation property on the collection is in the expected format, but the translation property on the field has not been deserialized from JSON (it's still a string):

"data": [
  {
    "collection": "translated_collection",
    "fields": {
      "translated_field": { ..., "translation": "{\"en-US\":\"THIS IS TRANSLATED\"}" }
    },
    "translation": { "en-US": "TRANSLATED COLLECTION NAME" },
    ...
  }
]

Other Context & Screenshots

I discovered this when looking into https://github.com/directus/app/issues/422 - it means that field translations can't be handled in the same way as collection name translations already are.

I tried investigating this and just got confused, but I wonder if it's something to do with the item.read filter in CoreServicesProvider.php being called for collection rows but not field rows when that endpoint is hit (that's how it appears based on putting some logging in there). I notice it is hit when the directus_settings fields are requested, and if you try adding a translation to the database for one of those fields it comes back in the expected deserialized JSON format.

Technical Details

• Device: Desktop
• OS: WSL Ubuntu 18.04 on Windows 10 1803
• Web Server: Apache/2.4.29 (Ubuntu)
• PHP Version: 7.2.10-0ubuntu0.18.04.1
• Database: Ver 14.14 Distrib 5.7.24, for Linux (x86_64)
• Install Method: Cloned master branch (and pulled just now, just in case)

[rijkvanzanten]

I think this is due to the fact that the record for this in directus_fields is still set to use TEXT instead of JSON. This field is hidden by default and isn't used anywhere (yet), so I'm not entirely sure if we should call it a bug or not :thinking:

[binary-koan]

@rijkvanzanten That was my thought too, but this is in my database (from the default install):

mysql> select * from directus_fields where collection = 'directus_fields' and field = 'translation';
+----+-----------------+-------------+------+-----------+---------+--------+------------+----------+----------+---------------+---------------+------+-------+-------+------+-------------+
| id | collection      | field       | type | interface | options | locked | validation | required | readonly | hidden_detail | hidden_browse | sort | width | group | note | translation |
+----+-----------------+-------------+------+-----------+---------+--------+------------+----------+----------+---------------+---------------+------+-------+-------+------+-------------+
| 37 | directus_fields | translation | json | code      | NULL    |      1 | NULL       |        0 |        0 |             0 |             0 | NULL |     4 |  NULL | NULL | NULL        |
+----+-----------------+-------------+------+-----------+---------+--------+------------+----------+----------+---------------+---------------+------+-------+-------+------+-------------+

It is arguable whether this is a bug as such - I mainly raised it as a bug because of the inconsistency between getting fields from the collections endpoint vs the fields endpoint.

[wellingguzman]

@binary-koan this was fixed by https://github.com/directus/api/commit/4020979eede7c6cf4f781fd3ee9277e9c964192c.

The issue here is the workflow of collection and fields is not the same for the rest of collections.

If you go to http://localhost:8080/_/fields/translated_collection/translated_field you would get the correct JSON instead of the string.

Now it parses the value of the json no matter what the field type is.