Support inspecting sessions

[mauritsvanrees]

This refs https://github.com/syslabcom/scrum/issues/2738 and I will make a PR in daimler.oira that uses this.

This lays a basis for "inspecting" sessions. What I mean with that, is that you can see all edit forms of a session, but with the form elements disabled.

This is meant for allowing to inspect archived or locked sessions. Until now that is not completely possible, because you are not allowed to view various pages because you have no edit rights anymore. Most importantly: the identification and action plan phases.

In webhelpers.py this PR sets:

allow_inspecting_archived_sessions = False
allow_inspecting_locked_sessions = False

With these settings, the new can_inspect_session method returns the same value as can_edit_session, so by default nothing should actually change. I will set this differently in daimler.oira so we can check it there.

The first two commits could be left out if wanted. The first is an optimisation to use @cached_property, which I like. The second is a small refactoring of the survey_tree_data method, which was my first approach for this issue, but it turned out to not be needed. Could still be useful though.

[mauritsvanrees]

Note that the parts that I touched did not really use z3c.form, so adapting updateWidgets or similar was not an option as far as I saw. I needed to change templates.

[reinhardt]

@ale-rt I can give this a review if you're busy with other things. I'm in psychosocial headspace anyway.

[reinhardt]

I wonder whether we also need to hide the save button(s) in the risk_identification_custom template. I haven't tested it yet, and in our GpB use case there are no custom risks AFAIK, but for completeness' sake we may want to cover those as well, right?

[ale-rt]

I would return a default which is stricter (e.g., self.is_manager).

[reinhardt]

I think that would contradict #2672. Non-manager GpB users are supposed to be able to inspect GpB sessions.

[mauritsvanrees]

I would agree that non-managers should be able to inspect sessions.

Note that currently we set allow_inspecting_locked_sessions = True in the class, but where wanted in a project (like daimler.oira) it could be overridden to something like this (using pseudocode):

@property
def allow_inspecting_locked_sessions(self):
    if self.is_manager:
        return True
    if this is a psychosocial session and user is NOT a psychosocial manager:
        return False
    return True

[mauritsvanrees]

In fact, I do a simpler version in the related daimler.oira PR.

[ale-rt]

I am still concerned by this default.
Like it is now, this needs an override in customers projects to fully have sense.
Anyway it's ok.

[mauritsvanrees]

I reported the default wrong in my comment above. In this Euphorie PR we set allow_inspecting_locked_sessions = False (same for archived).

With those defaults, can_inspect_session gives the same value as can_edit_session. So with the default settings this PR changes nothing:

• if you can edit a session you can inspect it
• if you can't edit a session you can't inspect it

This PR just makes it possible for policy packages like daimler.oira to set their own defaults, and make them dynamic where needed.

That said: I merge.

[ale-rt]

The first is an optimisation to use @cached_property, which I like

However, it's important to note that there are cases where it may not be the best choice. The @cached_property decorator works per instance, while the alternative combo works per request.

In some cases, such as when checking a registry record, memoize_contextless might be a better fit.

That said, I wouldn't recommend diving into a deep analysis of the code just to switch decorators, nor would I want to hijack a PR that's focused on something else to make this change. I’d prefer if such a change were driven by a clear rationale beyond personal preference, especially if it offers a significant advantage.

[ale-rt]

@ale-rt I can give this a review if you're busy with other things. I'm in psychosocial headspace anyway.

Thanks a lot @reinhardt, feel free to jump :)
Your suggestion was very much appreciated!

[mauritsvanrees]

I wonder whether we also need to hide the save button(s) in the risk_identification_custom template. I haven't tested it yet, and in our GpB use case there are no custom risks AFAIK, but for completeness' sake we may want to cover those as well, right?

Good point, thanks. I now handle custom risks as well.

[mauritsvanrees]

That said, I wouldn't recommend diving into a deep analysis of the code just to switch decorators, nor would I want to hijack a PR that's focused on something else to make this change.

Okay, I have removed my commit with the many @cached_property changes and have rebased and force pushed.