WMS GetCapabilities not returning the workspace prefix inside style names in 2.19.x

[giohappy]

MapStore expects to receive the the workspace prefix inside the style name returned by the GetCapabilities. It used to work in 2.18.x, even for GC requests toward workspaced services.
For example this request returns

Style>
  <Name>geonode:Major_Roads0</Name>
  <Title>A dark yellow line style</Title>
  <LegendURL width="20" height="20">
	<Format>image/png</Format>
	<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://stable.demo.geonode.org/geoserver/geonode/Major_Roads0/ows?service=WMS&amp;request=GetLegendGraphic&amp;format=image%2Fpng&amp;width=20&amp;height=20&amp;layer=Major_Roads0"/>
  </LegendURL>
</Style>

2.19.x doesn't return the workspace prefix anymore. A similar request returns

<Style>
  <Name>states</Name>
  <Title>A dark yellow polygon style</Title>
  <LegendURL width="20" height="20">
	<Format>image/png</Format>
	<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://development.demo.geonode.org/geoserver/geonode/states/ows?service=WMS&amp;request=GetLegendGraphic&amp;format=image%2Fpng&amp;width=20&amp;height=20&amp;layer=states"/>
  </LegendURL>
</Style>

Is this behaviour expected? Is the change on 2.19.x done on purpose?

The missing prefix breaks MapStore's Style Editor logic.

[giohappy]

@aaime can you shed some light on this?

[aaime]

The 2.19.x behavior is the correct one, if you're requesting on a workspace-specific capabilities document, all names must be de-qualified, including style ones, not just layer ones like in the past. It's something we fixed recently.

[giohappy]

thanks @aaime.
So MapStore built a functionality on top of a wrong behaviour of previous GS versions...

[allyoucanmap]

@giohappy @aaime I was working to improve the client but there is a case where I'm not able to recognize the correct workspace of a style.
See this comment GeoNode/geonode-mapstore-client#519 (comment)

[giohappy]

@aaime I undersand the rationale under the decsion of dropping the workspace prefix, but now I see a couple of inconsistencies.

Ambigous GetCap response

1. I create two style with same name under two different worspaces,
2. I assign them to one layer
3. I obtain the GetCap for one or the other workspace -> I have two styles with same name, title, etc. and I have no clue to know which one is what.
4. Which style will be used when I call the GetMap without prefixing the style with the workspace?

REST API response inconsistency

While testing other solutions based on the metadata returned from the API we notices that the workspace prefix has been stripped from the style response, but it's still used inside the layer response.
Is this behaviour done on purpose?

[giohappy]

quick report of the internal call:

• Geoserver shouldn't return any global style or styles from other workspacess when GetCaps are request is workspaced. The case was reproduced associating a global style, a style from the local workspace and a style from another workspace to same layer. The output is reported below.
• This causes name clashing in case the styles have the same name, but MapStore can safely pick any of them, since any subsequent (workspaced) request will use the style from the current workspace. As agreed this will be the solution that @allyoucanmap will adopt to solve the issue.
• REST APIs return namespaced names when they include references to resources. The reference to a style returned inside the layer API will remain namespaces, since it's out of the workspace naming control.