[16.0][FEAT]portal: new module to hide timesheet from portal

[quirino95]

This module hides details about timesheets and worked hours on tasks in the portal pages.

[HekkiMelody]

For adding a new module, the commit message should be

[ADD] project_portal_hide_timesheet: new module

(since the name of the module is already descriptive enough)

[HekkiMelody]

Minor formal changes but otherwise LGTM

[HekkiMelody]

chore:

Some formal requirements according to guidelines https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst

1. File name should be <model_name>_views.xml (I think _templates.xml is also acceptable here since there are templates)
2. These two views should be split on two files since one is related to the timesheet.sheet model and the other is related to project.task
3. When inheriting, the id of the new view should be the same as the original view (minus the module name), so id="portal_my_home_timesheet" and id="portal_tasks_list"

[HekkiMelody]

Code and functional review, LGTM

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[HekkiMelody]

@OCA/project-service-maintainers We've been using this successfully in production for a couple of months now. Could you please take a look? Thanks!

[dreispt]

Init hooks are a surprising way to modify views. It sounds dangerous.
I expected QWeb and view extensions to be used for that.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[alexey-pelykh]

Thanks for this contribution. The module approach is clean -- using post_init_hook/uninstall_hook to toggle existing portal views is a well-established OCA pattern, and the XML overrides are minimal and focused.

I reviewed the final commit (e5135a4) and the full review history. HekkiMelody's earlier feedback (missing sale_timesheet dep, loop-to-in operator, inactive record search, tests, XML split) has all been addressed. CI is green.

One item I'd flag:

Test coverage is vacuous (false positive)

In test_hooks.py, setUpClass fetches views with:

cls.views = cls.env["ir.ui.view"].search([("key", "in", views_to_switch)])

By the time tests run, post_init_hook has already fired during module installation, so these views are active=False. Since search() applies active_test=True by default, cls.views is an empty recordset.

Both assertions then pass vacuously because all() on an empty iterable returns True:

self.assertTrue(all(not v.active for v in self.views))  # True (empty)
self.assertTrue(all(v.active for v in self.views))       # True (empty)

To make the tests meaningful, the search in setUpClass should include inactive records:

cls.views = cls.env["ir.ui.view"].with_context(active_test=False).search(
    [("key", "in", views_to_switch)]
)

And assertions should also verify the recordset is non-empty, e.g.:

def test_post_init_hook(self):
    post_init_hook(self.env.cr, self.env.registry)
    self.assertTrue(self.views)
    self.assertTrue(all(not v.active for v in self.views))

Otherwise the hooks could be completely broken and tests would still pass.

Everything else looks good -- manifest, dependencies, license, XML structure, OCA scaffolding are all correct.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[SirPyTech]

Init hooks are a surprising way to modify views. It sounds dangerous.
I expected QWeb and view extensions to be used for that.

Thanks @dreispt for having a look!
Indeed hooks are not the usual way, I thought the same when I first saw this, but note that the hooks are only disabling the views, just as the user would do if they didn't want them.

I tried using xpaths but some of these views are adding several nodes here and there, and although hiding them all is possible, it results in a lot of xpaths in the new inherited view that could be hard to maintain.

We could save one hook adding the active="False" attribute in the views having id="original_module.original_view", but then reverting them on module uninstall is still needed and the list of views to activate would be far in the XML, so it's not easy to check that all the deactivated views have been activated back.

Please let me know what you think!

---

Test coverage is vacuous (false positive)

@alexey-pelykh it was indeed, I fixed it, please check again.