Upcoming changes to the [Group].[Type] column in v6.11
On occasion, it is necessary to improve the structure of the Reporting Database in such a way that existing SQL queries crafted by clients may require a small change to continue functioning.
This article provides advance notice of a planned alteration to the way Group information is represented in the Reporting Database.
The Elements product development roadmap includes plans to elevate Groups to be fully-fledged objects alongside Publications, Users, Professional Activities and many other categories of Elements data entity. This is planned so that, for example, metadata about Groups can be entered by clients that will later support the creation of rich public-facing departmental profile pages.
When the elevation of Groups to objects eventually happens, Groups will acquire the standard Elements concept of "Object Type". It is planned that at that time, a stock set of descriptive types will be made available for Group objects (such as "Department", "Faculty", and "Research Group").
However, the existing concept of Group type (such as "Primary group", "Auto group" and "Manual group") represents a blocker to these plans. These preliminary changes, to be released in v6.11, remove that blocker by renaming the existing concept of "group type" to "group membership model" throughout Elements.
A part of this renaming work will affect the Reporting Database.
The [Group] table's [Type] column will be renamed to [Membership Model]
From v6.11, the renamed column will contain the same values as before. For example, where previously the [Type] column might have contained a value of "Auto" or "Primary" (for Auto groups and Primary groups respectively), the renamed [Membership Model] column will contain the same values.
It is planned that a later version of Elements will reintroduce a new [Type] column that will contain values relating to the newer concept of Group Type such as "Department", "Research Group", or "Faculty".
How can I prepare for this?
You may wish to prepare for the change by reviewing any custom SQL your institution is using against the Reporting Database for any usage of the affected column, and plan accordingly. Depending on your level of engagement with the reporting platforms in Elements, this may include custom SQL-based dashboards, custom SSRS reports and custom integrations with downstream systems based on the Reporting Database.
Alternatively, you can simply wait until the release of v6.11 and then run your standard maintenance tests against your custom dashboards, SSRS reports and downstream integrations, detecting and resolving any issues at that time as a part of your upgrade project. As usual, we will release a technical upgrade guide providing step-by-step instructions for how to alter custom SQL to work with the new database structure at the time of the release of v6.11.