Issue & Reproduction Steps

DevLink bundle imports do not expose the destination user who initiated the installation to asset importers. This prevents package importers from assigning destination-owned resources correctly because identifiers such as a Dashboard user_id belong to the source instance.

To reproduce:

1. In instance A, create a Display Screen and a Custom Dashboard owned by a user from A.
2. Add the Dashboard to a DevLink bundle and publish it.
3. In instance B, install or reinstall the bundle as an administrator whose user ID differs from the source owner.
4. The importer only receives the import mode and cannot reliably assign the administrator from B as the resource owner.

Solution

• Add an optional, backward-compatible importingUserId context to Import/Export Options.
• Populate importingUserId from the DevLink Logger when installing bundle setting payloads.
• Propagate the same context through regular bundle installation and reinstall operations.
• Add coverage for the optional Options contract and reinstall context propagation.

How to Test

Run the focused core tests:

vendor/bin/phpunit tests/Feature/ImportExport/OptionsTest.php tests/Model/BundleTest.php tests/Model/DevLinkTest.php --no-coverage

Result: 10 tests and 33 assertions passed.

The package PR linked below contains the end-to-end Custom Dashboard installation, reinstall, and copy coverage.

Related Tickets & Packages

• https://processmaker.atlassian.net/browse/FOUR-32196
• https://processmaker.atlassian.net/browse/FOUR-24988
• package-dynamic-ui PR: https://github.com/ProcessMaker/package-dynamic-ui/pull/190

ci:deploy
ci:package-dynamic-ui:epic/FOUR-32196