[19.0][MIG] dms: Migration to 19.0

[dnplkndll]

Port of dms from 18.0 to 19.0

[pedrobaeza]

Thanks for the contribution.

Please preserve commit history following technical method explained in https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-19.0.

If the jump is between several versions, you have to modify the source branch in the main command to accommodate it to this circumstance.

[dnplkndll]

Thanks for the review @pedrobaeza — sorry I missed the technical method on the first round. I've now:

1. Rebuilt the branch using the wiki's procedure exactly:

   git checkout -b 19.0-mig-dms origin/19.0
   git format-patch --keep-subject --stdout origin/19.0..origin/18.0 -- dms | git am -3 --keep
   pre-commit run -a
   git add -A && git commit -m "[IMP] dms: pre-commit auto fixes" --no-verify
   

   176 commits from origin/18.0 are now preserved verbatim on the branch (you can see them in git log --oneline origin/19.0..HEAD | tail -20 — original authors / dates / subject lines retained).

2. Layered the [IMP] dms: pre-commit auto fixes and [19.0][MIG] dms: Migration to 19.0 commits on top.

3. Force-pushed to ledoent:19.0-mig-dms (PR description updated). Tests still 0 failed / 0 errors of 64 (with demo) / 42 (without demo).

CI is re-running now.

[dnplkndll]

Friendly ping @pedrobaeza @victoralmau @eLBati @etobella
— also note this supersedes #474 + #457, both of which are CI-red.

[etobella]

Using AI for coding is fine (I personally think it is a nice tool to improve your results), but you need to understand the code you're submitting.

In this PR specifically:

• Some functionalities were removed
• A lot of unnecessary diff was introduced

These are basic mistakes that would be caught by simply reviewing the changes your AI assistant supplied before opening a PR.

That is also a license risk: AI tools are trained on code with various licenses (GPL, MIT, Apache…). If you can't read the output, you can't detect contamination, missing attribution, or patent-encumbered patterns. Evenmore, you cannot claim ownership and copyright (completely necessary in an OpenSource community). "The AI wrote it" is not a legal defense.

Review what you ship, always.

[etobella]

Thanks for the partial response, but several inline comments were left unanswered...

More importantly, your own Phase 2 PR restores things that were removed in this PR (kanban buttons, breadcrumb, filter_domain). That is the clearest possible confirmation that functionality was silently dropped and went unnoticed — exactly the problem I feared in the review.

Please address all inline comments before requesting another review, and make sure this PR is complete and self-consistent before opening follow-ups to fix what it broke.

Vibecoding without knowing what you are doing is a problem for the code quality, for licensing, and for the reviewers who have to clean up after it.

So, can you justify all the actions done?

[dnplkndll]

@etobella certainly, thanks for the review! Apologies for the AI-review failure on the first round — I do try to keep it reined in. Your feedback is the best teacher; sometimes between all the notes and skill updates I wonder, but I believe next year the careful conventions will pay back in speed without losing quality. this PR feedback is delays as I fix my internal runboat.

for the reasoning on the button change I wanted to get the phase 2 IMP up. will try and get that later today.

Force-pushed

• Restores dms.KanbanButtons (Scan/Upload + file input) and the two attachment_*.esm.js files unchanged from 18.0. Caught one of my own bugs along the way — phase 1 initially restored the template but missed the buttonTemplate: "dms.KanbanButtons" wiring in file_kanban_view.esm.js, so the buttons would have rendered as orphan markup. Fixed.
• _search_starred: replaced the heavy operator-type-handling expansion with a 4-line minimal normalisation — the 19.0 Domain optimizer turns ('starred', '=', True) into ('starred', 'in', {True}), so we accept both shapes. The simpler 2-line 18.0 form alone broke test_starred on CI with AssertionError: 1 not found in []; the 4-line fix is the smallest delta that passes.
• Restores the onboarding_data.xml line-62 comment and keeps Command.link(ref(...)) tuples (the 19.0-correct form; the AI had inverted it to the legacy (4, ref(...)) tuples).
• Strips the 189-line whitespace reformat from views/storage.xml, keeping only the required expand="0" + string="Group By" removal.
• Modernises _(...) → self.env._(...) across directory.py, portal.py, and tests — prefer-env-translation (W8161) and translation-not-lazy (W8301) are in .pylintrc-mandatory and CI fails without them. Co-located with the _search_starred fix in [MIG] since both touch the same file; portal.py + test cleanups live in [IMP] pre-commit auto fixes.

Final scope: 31 files / +190-122 (down from 36 / +430-431, ~64% churn reduction). All 7 CI checks green.

A follow-up PR is opened as a draft preview on the ledoent fork: ledoent#2 — base = this PR's branch, so the diff visible there is only the phase-2 delta. Contents:

• Drop classic dms.KanbanButtons; rewire buttonTemplate to the modern dms.FileKanbanView.Buttons (single Upload, t-ref hook pattern). Mobile-Scan UX is intentionally dropped — the drop-zone (already wired via createFileDropZoneExtension()) covers mobile.
• Breadcrumb in path_owl.xml modernised from inline-style <a oe_form_uri> to Odoo 19's o_breadcrumb + breadcrumb-item Bootstrap idiom with aria-current="page".
• Restore filter_domain on dms_category.xml search (re-introduces the 18.0 ('parent_id', 'child_of', raw_value) parent-subtree filter that 19.0's default field-search lost; tag view left as default — 18.0's filter was equivalent there).

Deferred to a later round in that PR: JS dead-code audit (verification was inconclusive; core 19.0 LinkPreview has no native imageUrl getter, so the patches may still be load-bearing), coverage closure, code-style sweep.

Will promote ledoent#2 to an OCA upstream draft PR once this one lands

[etobella]

Even this response seems AI-generated.

Please, stop doing this, it is only making things worse @dnplkndll

We don't have yet an AI Policy, but I hope we will have one soon. meanwhile, you can see one example of what should be and shouldn't be allowed to be done with AI by checking other community policies...

https://github.com/pypa/pip/blob/main/AI_POLICY.md

[dnplkndll]

@etobella looking over the policy that matched up with the pycore team podcast from maintainers I just mentioned to @JordiBForgeFlow . I get it. the social part of this think is important and maintainers are not here to fix slop.

what I actually do is cli 6 sessions and always try my best to review and update. clarify fix everything I do. I understand I own it and I do understand the value of being the human. but I make mistakes. miss things, like I have in the past in many contributions I made before llms. but I can assure you I am present trying to be an enguaged policy following participant in the community. I continue to have much more grandiuos goals than my time and budget and am included to learn and grow with all the feedback I can get.

I will comment on your inlines and to be honest that last one I was like wth, but I did not then have time / remember to open that file to verify.

what is hard for me at this point is going through. then working on something else and a change happend in the wrong window I miss. I get it this is your time and will try to do better at making sure nothing hits the upstream repo intill I am ready to own it.