[FIX] Migration 194

[thirsch]

Proposed changes

Fixing the bug in migration v194, which prevented me from upgrading.

Issue(s)

Not sure, if there was an open issue.

How to test or reproduce

Migrating from v193 to v194 without having a settings entry for id "SAML_Custom_Default_user_data_fieldmap".

Screenshots

not adequate

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Improvement (non-breaking change which improves a current function)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Hotfix (a major bugfix that has to be merged asap)
• Documentation Update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• I have added necessary documentation (if applicable)
• Any dependent changes have been merged and published in downstream modules

Changelog

Fixed migration v194; in cases there is no SAML configuration, the database couldn't be migrated from v193 to v194.

Further comments

not required

[sampaiodiego]

thanks @thirsch .. just we know, from which version did you try to upgrade and got an error?

[thirsch]

@sampaiodiego is there an easy way to see migrations based on dates? Because I tried the upgrade multiple times before I recognized, that using the docker image migrates version by version and just crashed while applying version v194. So my database was v193 since the very first try and all my logs I still have, just show this try again and again. I guess I'm missing the first log on upgrading from whatever version I had before.

[sampaiodiego]

There is no easy way to see migrations based on dates, but from I what I saw migration 194 was introduced on version 3.4.0..

I'll be releasing this fix on version 3.5.1 today, so you'll be able to upgrade to 3.5.1, you'll only need to unlock the migration direct via DB.. you can use the following query:

db.migrations.update({}, { $set: { locked: false } })