I noticed a misbehaviour of the services ticks under workspaces.
Context: Services (WMS, WFS, ...) can be enabled/disabled either
globally under Services -> WMS or per Workspace: Select a workspace and
on the right side you find a panel with Services to be enabled/disabled.
Suppose you have a GeoServer configuration with global services
disabled. Enable Services per Workspace and then check the workspace
with the REST-API: When the Workspace-Service is disabled on the web
interface, you get back a 404:
curl -vv -u admin:geoserver -X GET http://localhost:8080/geoserver/rest/services/wms/workspaces/myOne/settings -H "accept: application/json" -H "content-type: application/json"
404 Service does not exist for workspace myOne
(I think that 404 is not documented in swagger, but that's OK.)
Now when ticking on the service from the web frontend (and
double-checking after saving that it is really on), I get back a 200,
but the service is "enabled":false.
--> I.e. state on the web front-end does not correspond to the REST
result: I would always expect it to be enabled: true, when not 404ing.
When looking a bit around the code I found out that in:
WorkSpaceEditPage$NewServiceModel.create()
the global state gets copied and is used for the workspace. So, if you
first enable the global service, then enable the workspace one, then
disable the global one, REST will report enabled:true as expected.
I'm unsure of any side-effects, at least the attached trivial patch
fixed the problem for me. WDYT?
Björn
(attachments)
0001-Fix-Internally-enable-workspace-services.patch (1.18 KB)