5.16.05.16.0

1. Web accessibility

We have prepared an updated version of our VPAT, which records our current status on meeting WCAG 2.1 accessibility requirements for the Pure Portal. We are proud that it shows we have made major steps towards making our portals fully accessible to all, keeping us on track for our goal of WCAG 2.1 AA compliance.

The document is available for visitors of your portal to view by clicking on the 'About web accessibility' link in the footer:

This will open our page on accessibility support. From here you can select to 'download the VPAT'.

2. Privacy and personal data

2.1. Access rights for non-active users

You can now configure a grace period so that former staff members can access Pure for a certain amount of time after they leave your institution. Institutions may require former-status personal users to access Pure: access may be required to fulfill policy or evaluation requirements and/or to ensure data is as complete and correct as possible. Access rights given through this feature are superseded by the general access rights of the institution and their single-sign-on (SSO) policies.

Click here for more details...

To configure grace periods for personal user (staff) and (student), go to Administrator > Users > Person access grace period. The grace period for personal user (staff) roles also applies to honorary and visiting scholars.

Setting a grace period
For personal users that are either students or staff, administrators can set an access grace period (in days). Once they become 'former' in Pure, the users will still be able to add and edit only their own content in Pure.
Important notes
If a personal user has both staff and student roles, the longer grace access period is applicable. If users have elevated roles (Editors of .../Administrators of ... etc), the users will retain these roles in the access grace period. Administrators should remove these elevated roles if required.

 

 

For an institution, balancing the functionality and value of a RIM/CRIS/Repository system with GDPR (and similar privacy frameworks) can be difficult. The bulk delete feature introduced in this release provides administrative users the ability to bulk delete sensitive fields from person records, giving institutions the tools to effectively manage this balance.

Some information will be retained to ensure any underlying data models function effectively, and to ensure Pure functions correctly.

Administrators can access this feature as a Bulk edit operation on persons, and can select persons based on multiple criteria, using personal information that is available in the specific Pure installation.

Click here for more details...

The following is a brief description of the process of filtering and selecting persons to have personal data deleted. An overview of the configuration options available with this feature is also included.

Filtering and selection
1. Persons to be considered for data cleanup can be filtered using two options: The various filters provided in the person content type list view and A pre-configured Personal data cleanup filter at Master data > Persons > Personal data cleanup. More information on the configuration options can be found further in the configuration section.
2. Once you have created a list of persons to clean up, use the checkboxes to select some or all of the persons (1). The Bulk edit button is then shown (2).
3. Select the Data cleanup option from the Bulk edit window, and click Next.
Deletion process
1. Select the fields to be deleted using the checkboxes. Warning: Some fields require special attention due to the actions of other other features/jobs and underlying data models. Sync jobs If a sync symbol is present next to a field, this means that the values in these fields are synchronized via a sync job. Even if you change/delete the value for the person(s), the sync job will re-add it once it runs again. Default values for data model purposes For fields required for the underlying data models to function correctly, default values are applied. For example, with Gender the value is set to Unknown. For Organizations, the link between the person and the organization is retained, but any supplemental information is deleted. 2. Once you have selected the fields that should be cleaned, click Next.
2. A warning message is displayed. This states the number of persons that will be affected. Importantly, it also informs you that the field values for those person records cannot be restored.
3. Once the Apply the changes button has been clicked, the relevant person data is deleted/modified and a downloadable log of the bulk operation is available. The person record(s) are updated and this can be confirmed by clicking on the person record and viewing the fields in the editor.
Configuration process
1. You can configure the bulk edit form so that certain fields are checked by default. Go to Administrator > Persons > Data cleanup configuration (1). Select which fields (2) should be pre-checked using the Standard list of fields to delete section.
2. The Personal data cleanup filter in the Master data > Persons tab (1) can be configured. You can access the configuration options on the Administrator > Persons > Data cleanup configuration tab (2). You can configure the Personal data cleanup filter to include persons based on: how long the person's affiliation status has been former the person type
Exempting persons from data cleanup
You can use the filter Exempted from data cleanup to ensure that persons who should not be deleted are not accidentally subject to data cleaning. You should firstly add persons to the exemption list. Then, before bulk selecting persons the Data cleanup bulk edit action should be performed on, you should ensure that you are also using the Exempted from data cleanup filter so that these persons are not selected. This process is described in detail below.
To add person(s) to the exemption list, select the persons to be exempted in the content list view by: Using filters or searching to locate the persons you want to exempt Clicking the tick icon in the top left of the content list view to expose checkboxes next to the persons' names. Selecting the checkboxes for these people, either individually or by selecting all.
2. Click Bulk edit, and Mark for data cleanup exemption.
3. Select an exemption period. You can select: One month Three months Six months One year After this time has passed, the persons you are bulk editing will be automatically removed from the Exempted from data cleanup filter. An exemption period can be selected, wherein the person(s) will be added to the list for data cleanup exemption for the specified time period.
4. After you click Apply the changes, a confirmation screen is shown. This confirms that the exemption was applied. You can download a log file of the bulk operation.
5. You can view Exemption status of an individual person on the Person editor window > History and comments tab > Data cleanup policy section. Here you can see: Any user actions that exempted this person in the History section. An option to manually exempt or include the person in the data cleanup in the Data cleanup policy section. The date that the person is exempt from data cleaning until.
6. You can use the Master data > Persons > Exempted from data cleanup filter, selecting Only show exempted persons, to see a list of persons who are exempted from data cleanup.
7. When you perform a data cleanup bulk edit operation, you MUST remember to firstly apply the Exempted from data cleanup filter and select the option Hide persons exempted from cleanup. When you then perform data cleanup, the persons that you configured to be exempt from cleanup are not affected.

 

 

In this release we have limited which attributes and related content, specifically awards, funders and usernames, can be searched upon in either Pure, or in Pure or Custom portals, depending on visibility statuses. This lowers the likelihood of confidential information being made publicly available.

The fix introduced in this release ensures that any indexing of public content, related to any confidential content, accounts for all possible permission options when searching.

Institutions that fall under the GDPR (or similar) framework may occasionally not gain approval from visitors for their identifying data to be available in activities. However, these institutions may rely on recording all activities for internal evaluations, which if not included in Pure may negatively affect the evaluation.

With this release, you can now set the visibility on Activities, so that Activities can be entered into Pure without the data being made available elsewhere.

You can do this from the drop down list in the Activity editor window. You must save the record afterwards.

For privacy reasons, now only Administrator or Administrator of Users can see the roles of users when adding a trusted user.

3. Pure Core: Administration

With 5.16 you can now track acceptance of your institution's Terms of Agreement when using Pure. This change makes it easier to access this information, and see specifically which version was agreed to.

You can explicitly see which Terms of Agreement each user has agreed to:

• in the User editor window > Agreed terms tab (the latest accepted terms of agreement).
• in the new reporting module
• in the audit log (full terms of agreement that were agreed to)

Scopus provides publication data with all content indexed in Scopus. Occasionally, dates provided by the journals, and shown on Scopus.com, are vague - for example 'Spring 2019', or 'January 2019' or '2019'. Scopus provides an approximation service that fills in 'missing' month and day information. As a result, content with a journal-provided date such as March 2019 appears in Pure as '1st of March 2019'.

To ensure that the content found in Pure best reflects the date found in the journal, we have introduced a configurable feature. This allows administrative users to:

• configure content imported from Scopus to use the exact journal date versus the approximated date,
• backfill content already imported from Scopus.

The feature will not overwrite any manually changed publication dates, and is disabled by default.

Click here for more details...

For REF customers

Before enabling this feature and/or back filling content, REF customers should note: Running the run once job could change the publication date on content that has been proposed to REF2021, in some cases removing the full publication date. This might have implications in relation to REF compliance. We recommend to first run the job on your test servers to see the implications of the job in relation to REF2021.

 

Example record from Scopus.com

Provided below is an example of the publication date as seen in Scopus.com for the record with Scopus ID: 85058052904. The publication date, as of the writing of this release note text, is January 2019 and reflects the journal's representation of the publication date. However, the publication date when imported into Pure is represented as '1 January 2019' due to the data provided via the Scopus API.

Configuration options to use exact journal versus approximated publication dates

Configuring Scopus as an import source for future content import:
Note: For imports from Scopus, you must have enabled Scopus as an import source. Navigate to Administrator > Research outputs > Import Sources. In the Scopus section, click Edit (1). If you want to use approximated dates, set 'Use approximated publication date' (2) to TRUE. Content imported from Scopus into Pure will use the Scopus approximated date. If you want to use exact journal publication dates, set 'Use approximated publication date' (2) to FALSE. Content imported from Scopus into Pure will use the exact journal date and not the Scopus approximated date.
To use exact journal dates on all previously imported content:
A single run job has been created that will convert all content previously imported from Scopus to use exact journal dates. This job will not overwrite any manual publication date changes even if the content was imported from Scopus. To use the job: Disable (set to False) approximated dates using the 'Use approximated publication date' option described above. Go to Administrator > Jobs > Single run jobs. Start the job 'Convert Scopus publication dates'. Important note If you convert all previously-imported content to use exact journal dates, you will not be able to use the same job to convert back to using approximated dates.
Once the job has run, you can inspect the results in the job log by clicking on the job run date. Users can use the dropdown filter and search option to view successes, or warnings if records were not processed. Success status information includes: Publication date updated from XXXX to YYYY No changes made (approximated publication date is the same as the journal provided publication date) Warning status information includes: Publication date could not be parsed as the Research output does not contain import source data from Scopus Skipping record (Scopus XML on the research output could not be parsed) Skipping record (publication status not set or publication status date not set).
If you are a QABO customer:
To ensure all content imported from Scopus uses approximated dates: Enable approximated dates using the 'Use approximated publication date' option described above. Go to Administrator > Jobs > Cron job scheduling.  Enable (if not already enabled) the job 'Scopus Publication Update'. Start the job. To ensure all content imported from Scopus uses exact journal dates: Disable approximated dates using the 'Use approximated publication date' option described above. Enable (if not already enabled) the job 'Scopus Publication Update' Start the job.
Important note for QABO customers: if you would like to process all previously-imported Scopus content, we suggest you enable 'Force update of all publications from Scopus' in the job configuration. Please remember to save any changes to the job configuration.

 

 

Journals increasingly allow more than one corresponding author on a publication. Additionally, the corresponding author title is often used in evaluations as assessments as a proxy indicator of a significant contribution to the publication. As such, in this release, Pure now allows you to set more than one corresponding author in a contributor list. The option to add corresponding author tags was introduced in 5.14, and, as well as allowing multiple corresponding authors, has also undergone some UX improvements.

Researchers, editors and administrators rely heavily on Applications providing the most relevant and timely data. An extremely important piece of data is the application submission deadline date. If a submission deadline is missed, an opportunity for funding is missed.

From this release, Pure allows the recording of a submission deadline date for applications. It is linked with any related funding opportunities and includes filters for approaching deadlines. It is only available for customers with the Award Management Module.

With 5.16 users can now search on full and partial DOIs in both the content list view search bar and the global search bar. This is another step towards improving the overall search experience, starting with identifiers.

Click here for more details...

Global search
Full DOI
Partial DOI
Content list search
Full DOI
Partial DOI

 

 

Previously, administrators were only able remove associated users from persons with help from Pure Support. We have now introduced the ability to manually and easily remove user associations directly within the Person editor window.

To do so, navigate to a Person's editor window > Associated user > Click on "Unlink associated user".

Typically, a Person and User must be linked for them to log in to Pure. However, if the user has roles beyond a 'personal user' they will still be able to log in. The elevated roles must removed by an administrator.

The "Unlink associated user" feature is deactivated if a Person sync job is enabled and the content is currently being synchronized. In this case the text shows: "You cannot manually unlink a user when the user information is synchronized from another system".

To ensure Pure customers enjoy the full support of our Pure support team, we have added messaging to encourage those who are not on the latest version to update.

This is a popup shown to Administrator users only, upon login to Pure.

As a reminder about support, Pure provides:

• full support for current active release
• fixes for one release back
• fixes for two releases back when all of the following are true:
  
  • in special cases
  • it is both agreed on between customer and Pure
  • it is a blocker or security issue
• no support for installations three releases behind the current version.

It is now possible to add a URL to a journal website. This makes it easier for users to access the journal website, especially for those journals that do not have an ISSN or similar common identifier.

For persons/users who have elevated roles, such as Administrator of applications role as well as Editor (Application - Checking) and Editor (Application - Approving), it can be burdensome to find and check the various workflow steps they have been assigned to. 

We have introduced user-specific Checker and Approver overview filters to improve ease of use and increase efficiency,

All data modifications by jobs that run in Pure are now clearly marked in the audit log with the name of the job that made modifications. This extends the improvements that were first introduced in 5.14 (Improvements to naming of job activity in audit logs).

4. Pure Core: Web services

The WSFileRef element has been updated to display more meaningful data.

The child elements DigestAlgorithm and Digest have been removed. This is because Digest didn't correctly match the referenced filed if coversheets are enabled.

Instead, the child element PureId has been added instead. This ID accurately indicates which file is being referred to. If the file is updated in Pure, the PureID is different the next time this element is returned.

Below are examples of the new output.

Configuration of person sensitive data fields has been moved to individual API keys. Instead of being a global configuration for the web service these fields are now configured on an API key level.

Existing API keys will inherit the old global configuration and new API keys will default to the most restrictive setting. The fields that can currently being restricted are:

• Gender
• Date of Birth
• Nationality

The old global values could be found in Administration > Persons >Web service configuration. This page no longer exists.

The API key configuration can now be found on the API key itself at the bottom of the page.

5. Integrations

In this release the integration with DataSearch replaces the Mendeley Data integration, expanding the coverage of this search functionality to a wide range of institutional repositories and other data sources.

Customers who had an active integration with Mendeley Data will be migrated to DataSearch and will automatically be limited to Mendeley Data from the list of sources in DataSearch, but can change the sources as they please.

More information on DataSearch and its integration with Pure is available here.

The DataSearch functionality can be found under Administrator > Datasets. By enabling this integration, datasets relevant to an institution are automatically imported into Pure.

The integration with DataSearch can be set up through the configuration page, through the following steps:

1. Navigate to Administrator > Datasets > DataSearch. Note: You must have Datasets enabled on your Pure to set up the integration with DataSearch.
2. Turn on/off DataSearch integration, which disables the corresponding cron job.
3. Specify either your institution ids or your institution names.  For clients with a DataSearch subscription it is a viable option to specify institution ids. DataSearch enriches harvested data from other repositories with institution ids and makes these available to search for through their API, but this is only available as a part of the paid integration.  If you make use of the free API, the best approach is to limit using your institution name(s). The reason for this is that in the free API the enriched ids from the paid API are not available to search for.  Currently it is not possible to both limit using ids and names as the DataSearch API handles this as an "AND" query, which will return a very limited result or no result. This will be changed in a future version of the DataSearch API to an "OR".
4. Set the default managing organization to be associated with datasets, if no other organization is found on the dataset's metadata.
5. Define the Workflow step to be given to datasets imported through DataSearch in the Dataset workflow settings section.
6. Select one or more data sources for import by listing their names in the DataSearch sources field. The names you enter must match the DataSearch source names exactly. Note: By clicking on "Show available sources", a list of available source names will appear. This is not the full list of sources as this is currently too comprehensive to show in Pure. For a full list of sources available go to: https://api.datasearch.elsevier.com/api/v2/sources An example from this document for Mendeley data looks like this: {"id":"MENDELEY_DATA","label":"Mendeley Data","providerName":"Mendeley Data"} In order to then limit to this repository you need to enter the id value into the source field. In this case that would be MENDELEY_DATA
Once the cron job is completed, users are presented with a preview of dataset import candidates. They can then update existing datasets or reject candidates.
Datasets that are rejected will automatically be excluded when the job runs again. Rejected candidates will be shown at the bottom of the Administrator > Datasets > DataSearch configuration page. If you select a rejected candidate and click the button Clear rejected candidates, it will be included again at the next run.

Co-managing organization information is now available in the web service. It is available on awards, applications and projects. The code snippet below provides a view of the relevant XML tags in the responses from the web service. For more information on how to enable and add co-managing organizations, see the section in these release notes on Co-managing organizations.

For example, in /applications, co-managing organization information has the following format.

 <coManagingOrganisationalUnits>
 <coManagingOrganisationalUnit uuid="...">
 <link ref="content" href="..."/>
 <name formatted="false">
 <text locale="en_GB">Department of Clinical Medicine</text>
 </name>
 <type pureId="..." uri="/dk/atira/pure/organisation/organisationtypes/organisation/department">
 <term formatted="false">
 <text locale="en_GB">Department</text>
 </term>
 </type>
 </coManagingOrganisationalUnit>
 </coManagingOrganisationalUnits>

This change is only relevant for customers using the masterlist import.

In this release the masterlist configuration has been moved from file to database. The masterlist configuration was previously stored in the local file system and accessible via a file handle. This has now been moved to the database, so when data is imported from the database, the masterlist configuration will be included automatically.

The old masterlist configuration will be migrated to the new database version. If you are a self-hosted client, then to check if any errors occurred during the migration of the masterlist configuration, please look into the console log. If one of the following errors occur, then please contact Pure support:

No valid MasterlistOrganisationSyncConfiguration found. Creating new configuration...

No valid MasterlistPersonSyncConfiguration found. Creating new configuration...

If you have not used masterlist before this is fine. If you have then we cannot validate your configuration and you should contact Pure support.

6. Unified Project Model and Award Management

This release introduces a feature that allows for co-managing organizations on awards, applications and projects.

This feature gives multiple organizations within an institution the ability to better understand their contributions to an award, application or project. It allows for greater visibility, control and communication between editors across the participating organizations, and is no longer limited to only those in the managing organization. The co-managing editor role, an extension of the current Editor and Assisting Editor roles, has been introduced to take full advantage of these benefits.

The co-managing organizations feature is configurable and disabled by default.

7. Pure Portal

The 'Contact Expert' functionality on Pure Portals has undergone a significant reworking based on feedback from our clients and users. These changes were made with three main goals:

1. To streamline the process for interested parties to get in touch with members of your institution
2. To make it easier and provide flexibility for your institution in managing incoming messages
3. To protect email addresses from programs which spider through web pages looking for email addresses

Click here for more details...Title

Previously, the 'Contact Expert' link could be configured to either:

1. provide a "mailto:" link to a researcher's email address, to open in your mail client.
2. link to an external page - for instance a web form on your institutional website.

The link displayed on the profile page, or it could be configured to show the email address directly. This is problematic as it leaves email addresses vulnerable to harvesters. Note, this functionality remains in 5.16, but we will consider removing it in later versions, also taking your feedback into account.

In 5.16, the first change is we have made the link more prominent on the page, turning it into a button. This is to better draw the eye of the visitor and so drive more engagement with your research assets:

Secondly, we have integrated a new web form into the design, which opens when the 'Contact Expert' button is clicked:

The web form provides separate fields each for the subject, message, sender name and sender email address. The form also includes a CAPTCHA as a protection against automated spam. Once the Portal visitor has filled in all required fields she clicks "Send" and the message is dispatched. She can also opt to receive a copy of the mail sent to her own email address.

The final, but most important change is in how the recipient of the mail is configured. This can be set via the backend configuration settings for 'Contact Expert'.

Backend configuration settings

The first step is to enable the feature. This is done by going to Administrator > Pure Portal > Configuration > Content Types > 'Edit' Persons > Enable contact expert.

Once enabled, you have a few options:

• Choosing whether to use the deafault Pure Portal web form, or to use an external link to your own web form
• Choosing which email address is used (recipient rules)

Using the web form or an external link

If you choose that the 'Contact Expert' button should open 'An external web link', this will bypass the Pure web form and link the button directly to an external webpage (for instance, on your institution's central website). When you select this option, a further field will appear where you can add the URL as the page you would like to link.

Select "Pure's default 'Contact Experts' web form" to use the Pure web form, as described above.

Recipient rules

You can choose whether:

• Emails sent via the contact form to go directly to the researcher
  • Emails are sent to the 'address associated with the organizational affiliation': Pure checks first if the primary affiliation has an associated email address and send the mail to this address. If one is not found, it will move down through subsequent affiliations. If an address is not found, it will attempt to default to the address of one of these organizations themselves, again starting with the primary affiliation and working down. If still no address is found, the mail will be sent to your institution's default 'contact email address, which is configured on the main 'Configurations' tab.
• Pure should bypass researcher email addresses and search only for department addresses, following the cascading rules above.

 

 

It has come to our attention that there was some confusion about the job "Update fingerprint data". Some clients may have been running it periodically, under the impression that it is necessary to do so in order to keep fingerprints current.

However, this is a "vendor" job, which only needs to be run when triggered by Elsevier in cases where (such as in this release) we update to use a newer version of the fingerprint job. Therefore, this job will be hidden to clients from now, so as to remove the possibility of confusion.

When "in version" updates to thesauri are available, these will be synchronized automatically via a separate job once a month, with timings staggered across servers. No action is required here by you the client.

We continuously monitor and review how discoverable Pure Portals are in search engines and make regular adjustments accordingly. In this release, we have focused on reviewing which pages should not be indexed by search engines, and ensuring appropriate page tagging is in place to communicate this to the web crawlers indexing the content. 

It could be advantageous to not index certain pages for many reasons - either the page contains less relevant or interesting content for searchers (e.g. a cookie information page), or the page contains information that is duplicated in full or in part elsewhere. 

Search engines determine the index ranking for your portal based on a multitude of factors, but one of these is an estimate of the average "searcher value" of the indexed pages. If pages adding little or no value are added to the index, then this average goes down, and therefore so can your page rankings.

 In this release, among the additional pages marked for not indexing are the "tab alternate" versions of profile pages.

Here, we have revisited the popular new "Click to Share" functionality from the previous release and delivered an improvement to allows PlumX to track social shares and usage. This engagement will then contribute towards the content's altmetric scores.

This is facilitated by adding the DOI to the data we share with the platform. If the DOI is removed, or unavailable, the data cannot be tracked. More improvements and refinements to Click to Share are set to follow in coming releases, including improvements to allow tracking via additional identifiers, e.g. ISBN, PMID, etc.)

*Due to testing constraints, this improvement unfortunately did not make the release cut-off date for 5.16.0, but will follow in the 5.16.12 update. However, we think it is important to still give advance notice of this functionality and to make it visible in the major release notes. This note will be repeated in the 5.16.2 release notes also.

8. Country-specific features

In this release we have made a number of updates to the REF module:

9. Additional features of this release

In order to be more transparent about changes to text and translation that may affect your edited text resources, with this release we are introducing a series of PDFs that describe all of the text changes made to Pure for backend UI locales (not the Pure Portals' text or locales). This shows which texts were added or changed between major releases.

If you have made extensive edits to text resources, you can refer to this file to see where keys have changed - in this situation your custom edits will be overwritten. Note that not all of the texts shown in the PDF may be able to be edited directly as text resources.

As always, we encourage you to download a spreadsheet of your custom edits before upgrading using the Administrator > Messages and Text Resources > Text resources > Export ODS button so you can refer back to the text edits that were shown in your previous version.

You can access the changes files here (PDF): Welsh, German, Dutch, Danish, Finnish, Swedish, Spanish, Russian, Chinese (Simplified), as well as in the right-hand column at the top of the release notes.