GUNDI-4683: Inreach migration script MK1

[vgarcia13]

Relevant Link

https://allenai.atlassian.net/browse/GUNDI-4683

---

This pull request adds a new Django management command script to automate the migration of Garmin InReach v1 integrations to the Gundi v2 system. The script handles the migration of integration records, configuration, and routing for both InReach-to-EarthRanger and EarthRanger-to-InReach workflows, providing detailed logging and error handling throughout the process.

Key additions and features:

Migration Command Implementation:

• Introduces a new management command (inreach_migration_script.py) that migrates Garmin InReach v1 bridge integrations to the v2 integration model, including organizations, integrations, actions, configurations, and routes.

Command-line Options and Filtering:

• Supports command-line arguments to select specific inbounds by ID, limit the number of migrations, or migrate all available inbounds using --inbounds, --max, and --all options.

Migration Logic and Error Handling:

• Implements transactional migration steps for both InReach-to-EarthRanger and EarthRanger-to-InReach, with detailed logging, summary reporting, and error handling to track created, skipped, and failed migrations.

Integration and Configuration Creation:

• Automates the creation or retrieval of related models such as Organization, Integration, IntegrationAction, IntegrationConfiguration, Route, and RouteConfiguration, ensuring proper association and field mapping between

[Copilot]

Pull Request Overview

This PR introduces a Django management command to migrate Garmin InReach v1 bridge integrations to the Gundi v2 system. The migration handles both InReach-to-EarthRanger and EarthRanger-to-InReach workflows with detailed logging and error handling.

• Creates a new management command (inreach_migration_script.py) with transaction-based migration logic
• Supports selective migration via command-line options (--inbounds, --max, --all)
• Implements comprehensive error handling and migration summary reporting

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The TODO comment indicates this logging configuration should be removed for production. Consider removing these lines or making them conditional based on environment variables to avoid accidentally running with modified logging levels in production.

[chrisdoehring]

I'm still puzzled by this. I think it still leaves open the chance to get an invalid Route Configuration assignment.

You might consider just creating a new one regardless of whether one exists. Or if you absolutely need to use get_or_create with name as the lookup, then do this:

Use integration's ID in the name rather than the human-friendly name. This to ensure it's not associated with a different route.

Consider what will happen if you do get an existing RouteConfiguration. If you do, this current code is not going to update the field mapping. But I suspect that's what you were intending.

[marianobrc]

Alternatively, we could force-update the route_config to ensure the field mapping is set properly. As it is now, the value in defaults will only be applied if the route config was created, then leaving old values if re-used.

[vgarcia13]

I think using integration's ID in the name for searching/creating the route config and if a route config is still found, an update should be done to ensure the data is correct

[chrisdoehring]

@vgarcia13 I left some comments. please have a look.

[marianobrc]

LGTM

[chrisdoehring]

Thanks @vgarcia13