Fix import custom objects on background

[kuzmany]

Q	A
Bug fix? (use the a.b branch)	[ ]
New feature/enhancement? (use the a.x branch)	[ ]
Deprecations?	[ ]
BC breaks? (use the c.x branch)	[ ]
Automated tests included?	[ ]
Related user documentation PR URL	mautic/mautic-documentation#...
Related developer documentation PR URL	mautic/developer-documentation#...
Issue(s) addressed	Fixes #...

Description:

If you import on background import failed with errors:

You do not have permission to create Items for Custom Object 3

The PR avoid check permission during import on background.

Steps to test this PR:

1. Open this PR for testing locally (see docs on testing PRs here)
2. Create import on background
3. Run bin/console mautic:import
4. See If import run correctly after PR

[escopecz]

I don't think this is the right fix for this. And I don't know why it works for us and not for you. But I think the proper fix would be to set the user in the ImportCommand because we know who scheduled the import job. So we'd just set that user to the UserHelper. This way users won't be able to go around the permission.

[kuzmany]

@escopecz I rewrite check permission for import creator on background processing.

[acquia-stalebot-platauto]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[acquia-stalebot-platauto]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please remove the stale label to avoid it being closed. Thank you for your contributions. More info: https://github.com/acquia/devops-github-administration/blob/main/docs/operations_related_to_repositories.md#acquia-stale-bot

[PierreAmmeloot]

@escopecz what can be done to help this subject move forward?

[escopecz]

The conflict must be resolved, the PR must be reviewed and tested.

[PierreAmmeloot]

I can help if you tell me how. :-)