V8-archive: API cannot go into deeper on user data

[anelad]

Bug Report

Steps to Reproduce

1. Add a User interface to a collection and name it publisher
2. Give user access permissions to the Public role
3. Send a GET request to _/items/aCollection/anID?fields=publisher.*.*
4. You will see the API is not getting into deeper on publisher field.

Expected Behavior

Getting deep information of the user, selected as publisher

Actual Behavior

No matter you do, API does not go deeper into the publisher

Other Context & Screenshots

Problem can be reproduced on directus.app

Technical Details

• Device: [4 vCpu Intel Xeon E5 2.6GHz/3.3GHz | 120 GB NVME SSD | 8 GB ECC RAM | Plesk Onyx 17.8.11 ]
• OS: [CentOS 7]
• Web Server: [Apache 2.4.37]
• PHP Version: [7.2.0]
• Database: [MySQL 10.2.26]
• Install Method: [cloned master branch | App: 7.6.1 API: 2.2.1]

[shealavington]

Can confirm this is an issue.

[benhaynes]

Any errors/logs? I wonder if this is an error due to the API trying to fetch some relational data on the user and the permissions are missing. Something like directus_user_roles...

Could we try this again with ALL directus_ collections publicly available? Not a solution, just trying to see if that might be the cause.

[bjgajjar]

@benhaynes

The user interface has an integer type. So we cant implement the condition on type integer as every integer has not contained User interface.

IMO, We should update the type of User interface as user same as user_created, datetime_created type.
PS. This will be a breakable change.

Let me know your thoughts.

[benhaynes]

This would be a question for @rijkvanzanten ... I understand the benefits of having a user type, but want to make sure this is the best solution.

Also, breaking changes will be hard. 🙁

[bjgajjar]

Agree but as per my knowledge that will be the better solution as per the current coding structure. As we cant implement the condition on interface.

[rijkvanzanten]

The user interface should be a many to one relation right?

[rijkvanzanten]

Yeah. Right now the user interface has the integer type which in turn doesn't allow the API to use it as a relational field. Changing the supported integer type to a m2o should fix it for new setups. Is this something we can write a migration for? I guess it's going to be a bit tricky, as you'll have to create the row in directus_relations too

[bjgajjar]

Changing the supported integer type to an m2o should fix it for new setups.

Cant we introduce another type User? As it's same like created_by, modified_by.
With that, we don't need to add that entry in directus_relations table. And ideally, we can handle this same as User Created interface.

Consider it as M2O or User; It will be breakable change only. So we can consider it as any of them.

[rijkvanzanten]

Fair! That also means we can write a single migrations on directus_fields instead of having to insert rows into directus_relations 👍

[bjgajjar]

migrations on directus_files

Hey, If I am correct then you are talking about directus_fields. Right?

[rijkvanzanten]

Yes 👍