Custom camp templates part 2: Share camps

[carlobeltrame]

• We want to enable users to visit "shared" marked camps.
• This option can be modified by the CAMP_MANAGER.
• The disclaimer on the sharing switch should explicitly list the exposed personal data, including in activities
• We want to make it clearly visible when a camp is shared. Both when I am collaborator in the camp and when I am viewing the camp as an outsider (but with different messages). This could happen via a banner similar to our offline banner, by marking the camp on the camps list, etc.
• Display who and when last activated the sharing switch. Store it as a DB reference to User / Profile

Individual activities can be copied manually from "shared" marked camps as well.
We don't intend these "shared" marked camps to be listed somewhere in eCamp.

For the following requirement, we are unsure about the performance penalties, and we want to test this separately (via a separate PR #8103) so that we can compare the performance on staging:

• Prevent access to camp collaborators related data for non-role-users. (team, personal material lists, dayresponsibles, activityresponsibles, comments)

[carlobeltrame]

When implementing this, the sentence "We don't intend these "shared" marked camps to be listed somewhere in eCamp." lead to unexpected complications.
I originally interpreted this as "The shared camps should not appear in the UI, and also not in the API collection endpoints."
However, the API part implies the following:

• If we want to hide the shared camp in the /camps endpoint, we still need to allow accessing it via the /camps/1a2b3c4d endpoint. Otherwise, the shared camp cannot be viewed for copying activities (assuming we don't want to introduce a completely separate endpoint /shared_camps/1a2b3c4d, which would mean lots of frontend components needs to be rewritten). This is a new inconsistency, but not a big problem in and of itself. It just means that the FilterByUserExtension, which generates a WHERE statement into our queries, won't be able to use the same WHERE condition for collections and for querying individual entities.
• All other entities can't be hidden in the collection endpoints at all, because many of them are primarily accessible via a filtered collection endpoint e.g. /periods?camp=/camps/1a2b3c4d. To handle this, we could force the API client to use a camp filter on all of these collection endpoints, or completely switch to subresources for all of them. That's a pretty big change which I think we didn't think of when writing that sentence.
  (Person-related entities in shared camps of course will need to be hidden in the API (i.e. /camp_collaborations, /day_responsibles, /activity_responsibles, /comments), and this is doable because we intend to handle their absence in all frontend views)
• On subresources, we have set a filter_by_current_user: false since opt out from FilterByUserExtension for subresources #7208, presumably for performance reasons. This will have to be removed for all person-related endpoints, because access to these entities is not guaranteed anymore when one is allowed to access the camp.

Since these changes are a little more broad than we probably imagined, I wanted to discuss this again.

The alternative would be to treat shared camps almost exactly the same as prototype camps (except that they are not offered in the UI when selecting a camp prototype): They appear "normally" in the API and are filtered out in the frontend. Of course, the changes above to the person-related entities access will still need to be implemented. One downside is also that if a camp is accidentally configured with isShared, the users' data is less well protected, i.e. these camps could in theory be scraped. What do you think?

[BacLuc]

I saw your pr and thought we could also work the other way around.
We set the prototype: true flag for the newly shared camps, and trigger the visibility in the prototype menu with an additional property.

That way you don't see the camp before you clone it, but it would add the value with minimal effort.

[carlobeltrame]

Yes, that's actually equivalent to the alternative I mentioned at the bottom of my previous comment. I would avoid just setting the prototype flag, I'd keep this setting separate, and just treat the isShared flag (almost) exactly the same as the isPrototype flag.

Side note: Keep in mind that one use case which we are trying to cover here involves "The read-only access should show (at least) the program, checklists and material lists." If we implemented something where you can't see the camp contents in the UI, but can only copy the whole camp, the use cases from #7445 would not be completely fulfilled. However, prototype camps can actually already be visited right now by anyone who knows the link, so you actually can see the camp before you clone it, and #7445 comes for free with your proposed shared-camps-are-like-prototype-camps approach.

However, the shared-camps-are-like-prototype-camps approach does not save us from some fine tuning. In the UI some things still need to be changed (buttons for editing or creating entities need to be hidden, the UI should be made more readable in readonly mode, etc.). Also, the following sentence from our definition isn't yet fulfilled with the "naïve" shared-camps-are-like-prototype-camps approach:

Prevent access to camp collaborators related data for non-role-users. (team, personal-materiallists, dayresponsibles, activityresponsibles, comments)

That sentence is where part of the complexity comes from:

• Caching gets harder when not all users get the same result on the same API call
• Person-related subresources cannot be exempt from our FilterByCurrentUser extension anymore
• The frontend will have to handle empty campCollaborations etc.
• Any camp marked as shared (even if accidental) is technically exposed on the API, which again may or may not clash with our specification "We don't intend these "shared" marked camps to be listed somewhere in eCamp", depending on your interpretation of "somewhere in eCamp"
• Filtering material lists and items gets more complex and maybe requires another DB VIEW
• Material Item visibility gets a lot more complicated: When copying an activity into another camp, we already copy the material items of personal material lists, but set the material list pointer to NULL (since Feature: MaterialList is nullable #7311). As a consequence, we have to replicate this "view" on reality in the API (overriding the materialList relation to be NULL when the material list is not accessible).

Thinking about this approach, I now think I have a clear enough picture so I can continue working on a first version which I can maybe show at the meeting, so it's easier to discuss.