[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 ( |
|
@kwoychesko thanks for your efforts on this.
2. Since v17 all sections have icons. I'd recommend you use the same icon from the homescreen of document_knowledge? IMO it looks odd not to have one for Knowledge.
https://github.com/OCA/knowledge/blob/18.0/document_knowledge/static/description/icon.svg
|
tonygalmiche
left a comment
There was a problem hiding this comment.
Functional review
Tested on a local Odoo 18.0 instance:
- Public pages correctly appear on the portal ("Knowledge Documents"), and private pages correctly follow the follower-based visibility.
- Category badges display correctly.
Found and confirmed 2 bugs in controllers/portal.py:
- Search bar doesn't filter anything — typing any search term still returns all pages. Root cause:
search_domainstarts as[](matches everything) and gets OR-ed with the real condition, which always matches everything regardless of the search term:
search_domain = []
if search_in in ("content", "all"):
search_domain = OR(
[
search_domain,
["|", ("name", "ilike", search), ("content", "ilike", search)],
]
)
domain += search_domain
- The search bar label displays raw HTML as literal text instead of rendering it, because the string is not marked safe:
"label": _('Search (in Content)'),
Confirmed fix for both (tested locally, works correctly):
from markupsafe import Markup
...
searchbar_inputs = {
"content": {
"input": "content",
"label": Markup(_('Search (in Content)')),
},
"all": {"input": "all", "label": _("Search in All")},
}
...
search
if search and search_in in ("content", "all"):
domain += ["|", ("name", "ilike", search), ("content", "ilike", search)]
Request changes with the fix above.


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.