[18.0][MIG] document_page_portal#615
Conversation
|
@marcelsavegnago — thanks in advance for reviewing 🙏 A heads-up on the red These are unreaped Chrome child processes in the CI container during HttpCase cleanup ( Is this a known issue with browser tours in the current image (possibly Chrome-version related, cf. OCA/oca-ci#122)? Happy to adjust the tests if you'd prefer a different approach (e.g. HTTP-level checks instead of full browser tours). Thanks! |
|
@kaynnan @pedrobaeza this should run clean now on a rebase / rerun ? |
|
@dnplkndll From what I see, yes, the rebase would already solve the tests that failed |
caa396d to
832a07b
Compare
|
@dnplkndll @kaynnan thanks for taking a look 🙏 Rebased onto the latest |
|
ping @pedrobaeza |
|
/ocabot migration document_page_portal |
|
@kwoychesko Can you improve the testing percentage? |
Cover the portal controller branches the browser tours do not exercise: the access-denied / missing-record redirect in document_pages_followup, and the date_begin/date_end filter of the document list. These use url_open (no browser), so coverage rises without adding Chrome tours.
|
@kaynnan Added HTTP-level controller tests ( |
Migration of
document_page_portalto 18.0. Part of #499.Changes during migration (beyond the mechanical pass)
<data>node;t-raw→t-out; Bootstrap 4 → 5 classes.views/assets.xmlto the manifestassetskey.web_tour.toursregistry API; the Python tests now usestart_tour.knowledge.group_document_user→document_knowledge.group_document_user.placeholder_countpattern (it was rendering hidden).portal.portal_record_layoutwith an inline card./web#…to/odoo/document.page/<id>.A separate
[IMP]commit improves the README (clearer DESCRIPTION/USAGE, fixed CREDITS link).Tested locally on 18.0: the module installs cleanly and both portal tours pass in a headless browser.