Unit migration

[robwa]

The semi-automatic migration works well for a simple example and is very helpful. However, it requires a good understanding of the new unit system. Many foodcoops will not have this in the beginning.

What happens:

1. I start the semi-automatic migration for a supplier.
2. I download an article backup.
3. I convert the articles to the best of my knowledge, but I may still lack understanding.
4. After the migration, I realise that my database is now incorrect.
5. I apply the backup, but it does not restore the database to its pre-migration state.
6. The ‘Start migration’ feature is now also no longer accessible, as the migration has already been carried out from Foodsoft's point of view.

Two problems:

1. The backup is not suited to restore the database.
2. The migration feature may only be used once.

[lentschi]

The backup is not suited to restore the database.

You're right: Currently it's just a backup in the sense of triggering a default CSV export. And any CSV import is just a very limited way of recovery as we all know.

The question is: How far do we want to take this feature? In theory it would be possible to not provide this "backup" function as a download but as setting some kind of recovery point in the database. But implementing this would be quite some effort (which we wanted to avoid for now to not further bloat the PR). Also it would be hard to impossible to return to such a recovery point once there are orders etc. based on the new articles.

Maybe it would be easiest to just inform the user what the CSV "backup" can do for them and what it cannot. And that - should they need a real recovery to before the automated migration in a worst case scenario - they'd need to ask their server admin to rollback to a db backup and accept loosing all the data since said db backup,

[robwa]

Would you agree if we opened an issue on this topic? From my point of view, it would be about finding out whether the CSV export could be improved in such a way that the content of the article database would actually be restored quite well.

[lentschi]

Sure. If you have a specific idea...? Or do you mean, you'd create an investigation/spike kind of issue? Either way, go ahead - I think none of us needs to ask for permission to create an issue 😅

[lentschi]

Also, it would helpful if you'd point out in exactly what ways you found the "backup" recovery from CSV lacking. (Either here or in your new issue.)
After all, maybe there's just a CSV import bug I have overlooked...?

[robwa]

Opened #1128 on that.

[lentschi]

The migration feature may only be used once.

Yes, it would be an easy change to leave the button in there forever. However, we actually invested a little time to make it go away after the first successful migration. ("It's a feature, not a bug" 😄 )

Our reasoning was: It'd be kind of quirky to still see the button, if you've already migrated - it would never go away (Or at least not until the feature has been removed from the foodsoft). Or do you have any other suggestion, when it should go away/return?

If you were just referring to the reimport of the CSV after a botched migration:
We could discuss adding a checkbox like "Re-enable automatic unit migration" at the CSV import view. (The CSV, after all, doesn't have any info that it had been exported during the auto-migration process.)

[robwa]

I can think of two ways to make the migration process repeatable:

1. a general setting as to whether the migration button should be displayed.
2. your suggestion: Enable re-display as an option during CSV import (I think that's a good idea!)

[lentschi]

your suggestion: Enable re-display as an option during CSV import (I think that's a good idea!)

👍 I created an issue for that: #1127

If someone has a different opinion (e.g. favoring 1.), please don't hesitate to say so. We can still drop said issue.