March
Goobi viewer Digest for March 2022
Last updated
Goobi viewer Digest for March 2022
Last updated
Performance for maps with many pins
Upload of records
Revision of the CMS area
ime and again it happens that an additional context is necessary for displayed content. For this purpose, the concept of works references was realised some time ago.
What is new now is a disclaimer modal that must be actively confirmed by visitors. This means that it is now possible to inform visitors more directly about sensitive content, for example from the field of ethnology or Jewish archival material, and to demand interaction/confirmation from the visitors.
In the backend, there is a new area called "Disclaimer" for this purpose, in which, in addition to activating or deactivating the functionality itself, the displayed text, the type of display and the validity can be controlled. The text in the modal can be formatted with HTML and stored in all active languages as usual.
For the display, it can be configured whether the modal is to be displayed in principle on every page of the Goobi viewer or only in certain data records. The data records can then be limited with a Solr query.
For the validity, either the browser session or a duration in days can be selected. This means, for example, that the modal must be confirmed the first time a page is called up and is then not displayed again within the browser session. Alternatively, the modal can also be displayed and confirmed only in certain records and this confirmation is then valid for a two weeks period, for example.
Provided the text is changed, the user's confirmation can be reset, analogous to the terms of use or the cookie banner.
The validity can also be overwritten in the rights area. This means, for example, that a notice can generally have a validity of 14 days, but within the reading room it can only have a validity of one browser session.
Work on the accessibility of the Goobi viewer continues steadily. In recent months, we have revised the use of tables on screen readers. In addition, the content of links and buttons has been reviewed so that links always call up pages and buttons always perform an action.
In the comments section, the concept of comment groups was completely redeveloped. The aim was that if several partners contribute content to a portal, the individual partners should have a simple overview and moderation option for the comments that have been written on data records of their own institution.
This requirement ultimately gave rise to the comment groups. These are based on a Solr query. All comments that have been created for the works within the Solr query are then visible. A comment group can then be released for a user group. This can be associated with the right to edit or delete comments themselves as well as email notification of new comments.
User accounts that are members of the user group then automatically receive access to the Backend. However, only the released comment group is accessible.
Furthermore, the administration of comments has been completely moved to the backend. Settings within the configuration file have to be migrated during an update. The corresponding section in the configuration file is omitted.
The terminology for access restrictions has been improved. Previously, we spoke of "access licences". Due to the word "licences" contained therein, there was often an association with "CC0" or "Public Domain", the licences of use. In order to make a clearer distinction here, from now on we will speak of "access restrictions" and "licences of use". All translations, help texts etc. have been adapted accordingly in the backend.
We are also slowly but steadily working on the usability of the search function. In the past month there have been two developments in this area.
One development concerns the advanced search and the display of drop-down menus. If there are now less than 10 entries available for a selected field, this is now done automatically. On the one hand, this eliminates the need to consider whether it makes sense to activate this option for all fields, and on the other hand, it increases usability considerably, as users are offered the corresponding values directly. The threshold value of 10 can also be adjusted via an attribute in the configuration file if required.
The other development concerns the search hit display. Especially when standard data is indexed, there are often long lists of values underneath each other with different notations. These values can now be displayed in one line for certain fields. This makes the display more compact and increases the overview.
The Goobi view Indexer can now distinguish between a new indexation and an updated record for METS files. This makes the reporting of URNs to the DNB via epicur / OAI more robust.
For a long time now, we have been working to continuously improve the development process. This month, we added a new facet where we integrated vulnerability checking into our workflow.
Specifically, this means that we automatically check the dependencies we use (for example, Java or JavaScript libraries) against the OWASP (Open Web Application Security Project) database using the Dependency Check Maven plugin. This tries to identify publicly known vulnerabilities in the dependencies of a project.
Of course, there are also false positives. These can be stored by us in a configuration file. Our goal is to go through all the comments, evaluate them and then flip a switch in the development process that lets builds fail automatically if a vulnerability with a CVSSv3 score greater than 5 appears in the project.
The versions that must be entered in the pom.xml of the theme in order to get the functions described in this digest are:
The Goobi viewer Indexer has the version number 22.03
The Goobi viewer Crowdsourcing Module has the version number 22.03
