Closed lexvand closed 5 years ago
Lex van Dolderen kan jij de workflow voor dit formulier nog delen?
by 5b03d19111b5d05139269675
Oh ja, Lex van Dolderen
Had jij nog een lijstje van wensen van de gebruikers wat ze van de wms zouden willen?
by madeleine.vanwinkel
Madeleine van Winkel See the Epic issue.
by lex.vandolderen
Tx! ��
by madeleine.vanwinkel
Als ik het wensenlijstje (zie de epic, https://nelen-schuurmans.atlassian.net/browse/GH-291 ) met de backend vergelijk, valt het volgende op:
api/v4
api/v3
Er is al afzonderlijk een url en een slug veld. Lex van Dolderen bedoel je een combinatie van deze 2 velden met URL (e.g. 'https://geoserver9.lizard.net/geoserver/almere/wms/') + slug (e.g. 'Duikers_verv_shapeli') (https://nelen-schuurmans.atlassian.net/browse/GH-291 )?
by madeleine.vanwinkel
Hey Casper,
There is a wish to make management screens for wms.
You can see the wish list in the description.
Comparing the wishlist with the backend, I notice the following:
api/v4
api/v3
Is it correct if I assume that api/v3 is static, and therefore, if organisation and shared with organisation have to be added, a new wms endpoint has to be made in api/v4?
by madeleine.vanwinkel
Is it correct if I assume that api/v3 is static, and therefore, if organisation and shared with organisation have to be added, a new wms endpoint has to be made in api/v4?
Yes, we will need to make a new API v4 endpoint for this.
by casper.vanderwel
I can already make a start on the wms management screens, but at this point organisation and shared with organisation cannot be added as options yet (we need the backend to implement that in a new api endpoint in api/v4).
The side note is also that currently, api/v3 will have to be used, because there is no api/v4 wms endpoint yet.
by madeleine.vanwinkel
And the WMS-layers endpoint should become writable right? not read only…
by 5b03d19111b5d05139269675
What we need is a list of fields, and per field:
For the rest: should we allow deletion?
We can of course make the list together. API/v3 is a good start point
by casper.vanderwel
Yes, deletion should be allowed.
by 5b03d19111b5d05139269675
Madeleine van Winkel The main URL of the WMS service and the layer slug are two attributes that are closely related, but they are separate items in the model. Because of their relation I thought it would be good to combine them in 1 step.
by lex.vandolderen
Should all the fields of the user requirements be read write?
by madeleine.vanwinkel
I’ve updated the description with what I think should be the requirements for the new wms endpoint.
Could you check whether the read/write / readonly property per wms property is according to the user requirements (and otherwise change them? (Blue in the description.)
by madeleine.vanwinkel
Lex van Dolderen can you make a ticket: implement Legends loaded from GetLegend url from wms-services in Lizard Portal and Lizard Dashboard and Lizard Atlas?
by 5b03d19111b5d05139269675
Lex van Dolderen Joeri Verheijden Madeleine van Winkel
Hi,
I checked the list of available fields above.
This makes me assume that:
Please let me know if my assumptions are correct, so I can proceed with this ticket.
kr Tom
by 5b3b278169812b2ef3f78d91
Hi,
Lex van Dolderen can you come up with reasons to add supplier. I don’t think it’s needed.
access_modifier is required on the client. A user should be able to make a WMS layer public, private or common.
Sorry for the late reply!
by 5b03d19111b5d05139269675
Joeri Verheijden Already discussed this with Tom. Only use of supplier would be to enable non-admins to manage layers that they are supplier of. But do we see that happen in any near future?
We have left it out for now. Access_modifier will be included.
by lex.vandolderen
Ok. It would make it consistent with raster management. Let’s add this feature.
by 5b03d19111b5d05139269675
In order to make wms layer management screens, a new wmslayer endpoint has to be added to api/v4.
User requirements
Technical requirements
Properties for new wmslayer endpoint for api/v4
from api/v3:
new for api/v4:
[FRNT-281] created by lex.vandolderen