Initial Data Migration to Directus - Setting user_created?

Help
1

My apologies for being full of questions today! I checked the docs and can’t seem to find an answer to this.

In a collection that I’m migrating from another system I added the optional user_created field. I’ll use row level permissions later to determine who has access to what.

During my migration process I’m migrating the user first then migrating their related data into Directus. While this is working great so far I’m wondering if there is a way I can override the user_created field for their migrated records?

I’d like to set the user_created field as part of the record when saving it, that way I can set it to the newly created owner’s Directus id. However, because I’m using the admin user’s static token every record has a user_created value of the admin user.

Is this something I can override as an admin user when migrating/creating records via the Javascript SDK?

EDIT: Or would the best practice solution be to create the user then, using the sdk, login as them or attempt to set their access token then use that during the creation of the related data records?

3

Hi @Chromag, Thanks for including the update, I checked with a colleague on this and one way you could do it is to do a patch request to update the value of user_created to the right user. Alternative you could disable the on_create for user_created to do nothing temporarily and pass in the value for user_created.

2

I could not find a solution to this so I decided to use by own owner field instead. This isn’t as straight forward as using the builtin optional user_created field but I think it will work.

Here is my proposed workflow:

  • Add an owner field to the collections that are being migrated and have an existing created column in the legacy tables
  • Add a new post-create Directus Flow that sets the owner field to accountability.user
  • Set the flow to inactive (this shouldn’t run during the migration process)
  • Perform migration, setting the owner field via the sdk
  • Set the flow to active (to ensure owner is automatically set for any newly created items)

If anyone knows of a way that I could use the builtin optional user_created field please let me know!

EDIT: It looks like I’m going to have to do the same thing with the date_created. Since I’d like to migrate this as well I’ll create a created_on field in the collection and use that instead. I’ll modify that same flow to populate both of these.

4

Hi Beth , thanks for your assistance! You’re absolutely right. I didn’t think about doing this. I’m using the SDK so I’m guessing the proper way to handle the patch request is to use the updateItem(...) function to update the record after it’s been created.

I tested this out and it works great. It is an additional API call which does slow down the migration process a bit, but it does work.

Is this something I can do in the UI? I dug around in the user_created field settings looking for on_create or any similar settings and didn’t see it.

I do like this option a bit better because it doesn’t involve an extra API call. This migration process will only be done once so disabling on_create during the initial migration and re-enabling it would be perfect.

But since it’s only done once, taking a little more time with an additional API call would also be fine.

Thanks again for your help.

EDIT: It seems like there is an option for On Create for the date_created field on the Schema tab. However, this option does not appear for the user_created field.