Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inspire theme doesnt have topConcept #1

Open
landryb opened this issue Jan 13, 2016 · 6 comments
Open

inspire theme doesnt have topConcept #1

landryb opened this issue Jan 13, 2016 · 6 comments
Assignees

Comments

@landryb
Copy link

landryb commented Jan 13, 2016

I see TopConcept were added to gemet thesaurus in 7bbfbed, but if i try to import inspire-theme.rdf from this repo in GN3 opening the editor page complains that this thesaurus doesn't have top concepts.
srv/fre/thesaurus.topconcept?_content_type=json&thesaurus=external.theme.inspire-theme is called, and that returns a 500 code with:

         "id": "error",
        "class": "TermNotFoundException",
        "service": "thesaurus.topconcept",
        "message": "No top concepts/keywords in file /data/webapps/geonetwork/config/codelist/external/thesauri/theme/inspire-theme.rdf",

@fxprunayre any idea ? Is it an issue in geonetwork handling of thesaurus without topconcepts, or those should be added to inspire-theme.rdf too ?

@fxprunayre
Copy link
Member

If there is no top concept, then the editor should fallback with default keyword picker. Can you still choose keyword from the thesaurus ?

@landryb
Copy link
Author

landryb commented Jan 14, 2016

Yes, you can still choose the keyword from the thesaurus, it's just that the 500 error code + 30 lines of traceback in the logfile is just ugly - the exception should be gracefully handled/logged as info/debug ? Now that i've tested adding keywords from both 'gemet concepts' and 'inspire themes' i see the UI differences in behaviour between thesaurus with and without topconcepts.

@fxprunayre
Copy link
Member

Fixed in geonetwork/core-geonetwork@3f419e3

@fxprunayre fxprunayre self-assigned this Jan 26, 2016
@landryb
Copy link
Author

landryb commented Jan 26, 2016

worth backporting to 3.0.x ?

@etj
Copy link
Member

etj commented Mar 10, 2016

I guess that fixes should be backported to stable branches.

@archaeogeek
Copy link

I'm still seeing this error in 3.0.5, so a big +1 for it being backported to the 3.0.x branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants