Upgrade SDI to Geonetwork 3.2
|Status:||In Progress||Start date:||Aug 30, 2018|
|Assignee:||Fabio Sinibaldi||% Done:|
|Infrastructure:||Development, Pre-Production, Production|
#6 Updated by Emmanuel Blondel almost 2 years ago
@firstname.lastname@example.org @email@example.com Any news on that? I see the ticket is set as 'urgent' since 10 month.. In our work on FAO-IRD Tuna Atlas, this became a blocker. Indeed, the HTML display in GN2 is not as powerful as in GN3, and we are not able to visualize HTML metadata views given the richness of metadata (an GN2 internal issue with parsing XML..). We are at now constrained to do an harvesting from a IRD GN3 instance, unfortunately only for testing, and we reached the point where we need ASAP to share links to stakeholders in FAO, IRD and RFMOs.
Can you tell us if we could get a GN3 instance for Tuna Atlas, and if yes, when?
Thank you so much in advance
#7 Updated by Fabio Sinibaldi almost 2 years ago
indeed the upgrade of GN took more time then estimated, also because the original development plan and SDI architecture changed according to communities needs. However, we should be able to provide such version from gcube 4.7 which will be released later this month.
#10 Updated by Fabio Sinibaldi almost 2 years ago
- % Done changed from 0 to 50
- Status changed from New to In Progress
The first configuration and migration tests from tuna atlas VRE's GN to the newer GN 3 instance in development infrastructure were successful.
NB : both marshalling (geoapi) and metadata validation (geonetwork webservice side) were disabled in order to deal with metadata files found in tuna atlas VRE's geonetwork.
#11 Updated by Emmanuel Blondel almost 2 years ago
Thanks Fabio. For your GN tests you can use the geonetwork metadata, but please provide us a empty GN3 instance as we will have anyway to run our workflow to see that publication is running well with Geonetwork 3, and then republish everything with our latest workflow changes. Thank you
#13 Updated by Fabio Sinibaldi almost 2 years ago
yes. I'm confident that GN 3 for tuna atlas will be ready to be used by the end of the week, probably before. I'm creating the ticket for a new machine right now. Once the service will be ready and configured in our Information System, the previous existing one will be dismissed.
#16 Updated by Fabio Sinibaldi almost 2 years ago
In order to provide the updated service to Tuna Atlas VRE, incompatibility with our library has been detected in 3.0.x versions.
3.2.1 works well, but 3.2.2 introduced the adoption of CSRF token, which requires additional logic in order to be handled.
#17 Updated by Emmanuel Blondel almost 2 years ago
FAO FI recently funded upgrade of geonetwork-manager to support GN3 REST API with backward compatibility for the other versions (2.6.x and 2.10x series). It was done by our external FAO partner Geosolutions IT (who developed the the geonetwork manager library used in your gCube wappers). The Java API was successfully tested with FAO GEMS tool which relies on geonetwork-manager. A maven release has been done (so you can access it).
I suggest you to upgrade geonetwork-manager if not yet done, to stick on more stable version of GN3 3.0.x, and not to enter to earlier in support the new REST API introduced with GN3.2.x since it's still in beta. If they are any issues related to geonetwork-manager Java client in interaction with GN 3.0.x series, please forward us so we could report them to the originator of geonetwork-manager on which you are mainly relying on
#18 Updated by Fabio Sinibaldi almost 2 years ago
The adoption of geonetwork-manager.1.4-SNAPSHOT is as old as this ticket (version was suggested by GeoSolutions team), and previous versions have been used to interact with geonetwork service since its adoption. Problem is that this library doesn't seem to offer ways to deal with users and groups, functionality that we had to implement extending the library provided by GeoSolutions.
The REST API is well documented from 3.2 so we've been able to develop on it, but in 3.0 it's more obscure.
In case I'm missing something, please tell me. It would solve lots of problems.
#19 Updated by Emmanuel Blondel almost 2 years ago
Hi Fabio, you can have a look to this file https://github.com/geonetwork/core-geonetwork/blob/3.0.x/web/src/main/webapp/WEB-INF/config/config-service-xml-api.xml that shed a bit of light on services for groups.
For example, you can retrieve the groups with
/geonetwork/srv/eng/xml.group.list?_content_type=xml (GET). This request gives you a way to retrieve the internal group ID given a group name.
In https://github.com/geonetwork/core-geonetwork/blob/3.0.x/web/src/main/webapp/WEB-INF/config/config-ui-metadata.xml there is some information for assigning privileges to metadata with
md.privileges.update (here I suspect an issue in geonetwork-manager that use
md.privileges instead, that i had to deal with in R geonapi).
md.privileges is the GET method to get privileges of a metadata,
md.privileges.update is to assign/update privileges.
With this method you can specify the groupId, previously retrieved from above method.
Apparently you can also switch a metadata from one group to another with
md.group.update but I didn't try.
I agree with you that it's obscure, and to be honest I don't really like GN3, too opaque,not enough documented and backward compatibility is broken in several features. The UI is not behaving well neither, they switched to AngularJS but badly handle Angular directives.