OutdoorSite not assigned to a portal can be assigned as children of another OudoorSite with a specific portal

[dtrucs]

To Reproduce
Steps to reproduce the behavior:

1. Go to the backoffice
2. Create an outdoorSite
3. Do not assign a portal
4. Create another outdoorSite
5. Assign a portal to this one
6. Define the first created outdoorSite as children of the second one

We should look at outdoorSites portals before linking them as parents/children.
At the very least, children which do not have the same portal as their parent should not be referenced in the list of children through the API.

[dtrucs]

To clarify the last point let's imagine we have:

• an outdoorSite parent { id: 1, portal:[10], children:[2] }
• an outdoorSite child { id: 2, portal: [] }

If we call the outdoorSite parent endpoint like following:

• /api/v2/outdoor_site/1/ it's okay to get children: [2]
• /api/v2/outdoor_site/1/?portals=10 it's not okay to get children: [2] (it should return children: [])

[babastienne]

Hum, I'm not sure about this issue. To me the portal mecanism is already quite complex and asking all territories to add a specific portal to each child item is not a good idea.

The childs are supposed to be in the same area as the parent, so maybe we can simplify the mecanism : when an outdoorsite is a child we remove the portals property and it will automatically inherit the portals of it's parent ? I don't see any scenario where it is relevant to put a different portal on a child ... 🤔

[dtrucs]

I don't see it either.
But technically it's possible.
In GTR, on every outdoorSite page there is a loop with the value children (with the portals parameter) and rise an exception because the API returns {"detail":"No Site matches the given query."}. In that case, maybe the API should return a 404 error?

[camillemonchicourt]

Yes, not sure how we should do.
But if we have to assign a portal to treks to publish them when we filter by portal, it makes sense to assign ALL objects to this portal to be coherent.

I find it more coherent to do like this than to do another special thing to automatically assign portals to children.

Even if you are in Geotrek-admin and wantr to filter all your treks assigned to a portal, it is important to also have assigned the children to portals:

It has never been a problem for my users that never asked me about that and assign portals to all objects they want to publish on each portal.

[babastienne]

I see multiples problems with portals (we diverge from the original issue but I think it's important to address the problem globally) :

• The location of the field "portals" in the interface is not easy to find (for example in treks you need to edit the treks, go to the tab "More details" and scroll and the bottom to find the field). It is one of the reasons sometimes users don't fill this field, and if it is related to the publication it should be next to the field "Published".
• The portal field seems redondant with the publication information. To simplify the behavior and help people being less confused the solution could be : 1. make mandatory the use of a portal on any Geotrek, even if there is only one portal connected. 2. Whenever someone want to publish something they don't have to check the field published AND select a portal, they'll just need to select a portal and if it is provided it will be automatically published on it. This way no user could forget to select a portal and it also solve the problem of the child outdoor sites discussed in this issue.

[camillemonchicourt]

Yes it would be a good thing to place this field with the publication fields in forms.
But it can be strange to have to assign a portal to each object when you dont have several portals.
But yes, we can also see the publication and portals fields a bit redondant. But we can also publish contents in several languages or not.