Version Committer information

[carolyncole]

We should keep the old version committer information, vs creating new information.

The version committer information lives in the database. Does the IngestFile Job create a new version committer record. What happens to the old record?

child of #1128

[carolyncole]

Looks like the version committer information is getting overridden by the move

[awead]

There's a batch user in the external files conversion service https://github.com/psu-stewardship/scholarsphere/blob/develop/app/services/external_files_conversion.rb#L12
Not sure why. Then the user is passed to IngestFileJob, which is adding the user to the VersionCommitter table. I still don't know why this doesn't appear when I do a migration locally, but I do see the batch user record added to the table when I run a local migration.

[carolyncole]

The mysql command run on QA to transform the version comitters is here: https://gist.github.com/cam156/247cd07e02349db2c0ba9828ea319791

[awead]

@Cam156 should this be done as a post-migration step?

[carolyncole]

@awead I think the reason you are not seeing the version issue locally is this line: https://github.com/samvera/curation_concerns/blob/master/app/presenters/curation_concerns/version_presenter.rb#L24 There are two records and you are just happening to get the oldest one first.
The reason we are seeing the version issue on dcefedora is that there is no other item becuase of the uris having production in them. We should likely not leave the extra version comitter record that contains the batch user in the system. Although I am not completely sold on that. The command above would be pre migration if it was anything.

[awead]

@Cam156 After running spec/services/external_files_conversion_spec.rb:26, I can verify that there are are two records in the VersionCommitter table, both with the same version_id, but one with the batch user email and the other with the original depositor email.

I think the easiest solution is to just delete the records with batch user in them. I looked at production and there are no records in the table with the batch user email. So we can assume that any ones created would come from the migration process and would be safe to ignore/remove.