app/nut database:export outputs unexpected results for multi-contenttype select fields

[simongroenewolt]

When running

app/nut database:export --file=export.yml --users

I noticed the output of many 'select' fields was a list of 'empty' fields like this:

routes:
    -
        slug: 4f33139afbd38339
        datecreated: '2020-10-01 10:05:41'
        datechanged: '2020-10-30 09:56:22'
        datepublish: '2020-10-01 10:04:57'
        datedepublish: ''
        ownerid: 3
        status: published
        templatefields: {  }
        spaces:
            - {  }
            - {  }
            - {  }
            - {  }
            - {  }
            - {  }
            - {  }
            - {  }
            ...

Details

Question	Answer
Relevant Bolt Version	3.7.5
Install type	Composer install
BC Break	no
PHP version	7.4

Reproduction

Create a contenttype with a specification like this:

routes:
    name: Routes
    singular_name: Route
    fields:
        spaces:
            type: select
            values: (contenttype1,contenttype2,contenttype3)/ref
            keys: slug
            autocomplete: true
            multiple: true
            sortable: true
            label: Ruimtes

Then add a couple of entries to the 'spaces' of contenttype1/2/3 and export using the database:export command.

It looks like the export command cannot handle select fields that have multiple contenttypes as 'target'.

Database fields for a select field targeting a single type look like this:

["2b391388d903331e","76ecac4f0c7e1593","b3e554ba84186142","235fcaf57bb4adf7","5462482fe2c0c61e","57e5716ffe1b5d51","d917543c11b341a7","860efdd2fff5642f","b0f99f60982d23df","15cb8ca97ba84211","533c98e2c949b4cf","cf92292976629202"]

Database fields for a select field targeting multiple types look like this:

["reflections/87c7bf2b8ebce56a","connections/107c618c639e021a","rooms/be777b7bb2952d17","rooms/63e5e415afe9695a","rooms/c3987cee9c663574","rooms/df2e286b5b1f6aab","connections/c1d75a2c79b4dd29","connections/c51308d0bdd029bb","rooms/63ec3d3e42c894bc","rooms/789480da0181c5c1","rooms/74b4c2a6b6738583"]

I've hacked up a crude fix that looks like it is working by making some changes to getReferencedContent() in Export.php . I'll create a PR when I've cleaned and tested it a bit more.

[simongroenewolt]

After looking some more at the code I think the default key is the 'id', so the 'slug' being used in this case might be an exception. The only place in the code where I see something that uses this is in Choice.php which looks like code related to the editor select box shown in the admin part.

My guess would be that the 'keys' option was originally meant for use with other sources of content than a related contentType, and at the same time bolt maybe accept both 'id' and 'slug' as selectors in lots of places? This could explain this 'interesting' situation that I'm in. (I didn't set up the original bolt 3 cms, so I don't know the original reason for using the keys: slug in the definition.