[18.0][MIG] base_export_async: migrate

[pierre-halleux]

No description provided.

[samirGuesmi]

Hello @pierre-halleux
Thanks for the PR! 👍 😄
There’s just a small adjustment I’d suggest to avoid the following issue:
TypeError: this.env._t is not a function

[RyanTranAVB]

@samirGuesmi I believe your comments are addressed, could you review once again?

[samirGuesmi]

LGTM @pierre-halleux could you please check this and approve the changes

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[pierre-halleux]

LGTM @pierre-halleux could you please check this and approve the changes

Thanks for the changes. LGTM

[fnegrini]

Thanks for this — migrating base_export_async is genuinely needed.
While testing a parallel port of my own (#)
against a live 18.0 instance (42k-row export, real email delivery), I
ran into three issues that also apply to this PR, flagging them here in
case they're useful regardless of which one ends up merging:

1. No access_token is generated for the attachment
   (export() never calls attachment.generate_access_token(), and the
   built URL has no access_token param). Without it,
   ir.attachment.validate_access() only grants access to the
   attachment's creator with an active session, so the emailed link
   404/403s for the recipient in the common case (different
   device/browser, or not logged in when opening the mail) - even the
   16.0 original only handled this for portal users; this drops it
   entirely, including the test_portal_export test that covered it.

2. model_description = self.env[model_name]._description stays
   English-only for every recipient, since _description is a raw
   Python class attribute, not a translated field. ir.model.name is
   the translate=True equivalent and can be read with the requesting
   user's lang (already available in params["context"]) to get the
   subject in their language.

3. if request: request.update_env(user=self.env.user) before
   calling core's unmodified ExcelExport() relies on request being
   bound, which is only true because queue_job's default runner
   executes jobs via an internal call to /queue_job/runjob. Under any
   runner/test path where the job executes without a live HTTP request,
   request is unbound, the guard silently no-ops, and
   ExportXlsxWriter.__init__ then fails on request.env[...].
   test_export_xls here sidesteps this by mocking
   ExcelExport.from_data directly, so the real code path isn't
   actually covered.

Happy to fold these directly into this PR instead of keeping mine
separate, whichever you/the maintainers prefer.

Look at: https://github.com/fnegrini/queue_export_assync_18/tree/18.0-mig-base_export_async

[StephaneMangin]

Once merged, there is an optimisation addition proposed here to avoid memory issues for very large exports. #1010.

[oca-cla-bot]

The following commit authors need to sign the Contributor License Agreement:

• 674416404@qq.com
• oca+oca-travis@odoo-community.org
• vvr@cowboy.com
• benjamin.coronel@factorlibre.com
• transbot@odoo-community.org
• pierre.halleux@acsone.eu
• arnaud.pineux@acsone.eu
• guewen.baconnier@camptocamp.com

[pierre-halleux]

Thanks a lot @fnegrini for the detailed report.

1. Access token: The 16.0 fix, "issuing tokens for portal recipients" was merged after I created this branch. I've now forward-ported it in 149a7763. Always issuing a token would change the 16.0 behaviour so I think this should be adressed in a dedicated PR.
2. Untranslated subject and 3. Request guard: I agree, but these are inherited from 16.0, so should also be handled in a separate PR imo.

Once this is merged, feel free to open those PRs from your branch and ping me. I'm happy to review them.

[pierre-halleux]

@StephaneMangin thanks, very we useful, we did encouter this issue as well previously.