Export/Import `core_admin_auth` configuration referencing `admin_roles` by `code` field instead of record `id`.

[psunderhaus-alto]

Export/Import core_admin_auth configuration referencing admin_roles by code field instead of record id.

Summary

I'll start by saying, I'm not sure that this is really in config-sync's control, but I've observed that when the core_admin_auth configuration is exported from the database, the values exported for the defaultRole and ssoLockedRoles fields reference the id field of the admin_roles table. I am wondering it is at all possible to reference the code field on this table instead of the id.

I am in a situation where my environments are a little out of sync in the admin_roles table. I've observed that the code field is identical whereas the id is not.

I understand it may not be possible to refer to the code field as this is Strapi's configuration and this plugin is simply making it portable. Do you have other advice? I'm still in development, so it is an option to hit the ol' reset button on these environments to clean things up, presumably alleviating my need for this. I'd have to put some other guard in place to ensure this table not fall out of sync again though.

If, in your opinion, it's much more reasonable to suggest Strapi be changed to use the code values in the core_admin_auth config, I think this plugin would "just work". I'm happy to take this to Strapi directly.

Why is it needed?

Record ids in the core_admin_auth config aren't exactly guaranteed to match up across environments. An alternative reference may help my case.

Suggested solution(s)

When exporting this configuration item, lookup the code field for the admin_roles referenced by id in the defaultRole and ssoLockedRoles fields. Export the code. On import, lookup the record id by the code and write the id to the database entry.

Related issue(s)/PR(s)

A cursory look at the repository history didn't turn anything up.

[boazpoolman]

Hi @psunderhaus-alto,

Thanks for reporting this issue. You bring a valid point to the table.

The plugin steers away from using id's for identification as much as possible. That auto-increment id just doesn't work nice across different databases (as you mentioned). And for the most part, the plugin can avoid them fairly well. Even relational field values can be ID'ed without using the actual id. Though for the specific config you're describing (core_admin_auth) it's more like a value dump. Not relational and no corresponding schema. This pretty much goes for the entire core_store config type btw. It's just random JSON storage.

That being said, in theory this can be fixed. But in reality, that would be an endless battle. Each new "magic" config value in the core_store table needs to get it's own exception.

Also, with Strapi v5 the uuids will replace the traditional auto-increment id. By then this issue will have resolved itself as those will be constant throughout databases.

[jacobsung]

Vote +1 for an earlier fix.

[psunderhaus-alto]

Also, with Strapi v5 the uuids will replace the traditional auto-increment id. By then this issue will have resolved itself as those will be constant throughout databases.

Interesting, Boaz, thanks for the background. What about the use of uuids across databases guarantees consistency when spanning databases? Is Strapi v5 using criteria other than record timestamps to produce the same id values?

[boazpoolman]

What about the use of uuids across databases guarantees consistency when spanning databases? Is Strapi v5 using criteria other than record timestamps to produce the same id values?

Yes. You can read about it's detailed design here: https://github.com/strapi/rfcs/blob/v5/database/rfcs/xxxx-v5-database.md#document-id-and-entry-id