GGCE 2025.1
2025.1.0 comes with a new implementation of APIs and an updated permission system, the UI uses more compact form layouts, and comes with an improved distribution module.
Please check the complete list of changes at:
- GGCE UI Changelog
- GGCE API Changelog
- See Upgrading GGCE for instructions
GGCE API v2
The long-awaited upgrade of GGCE API is finally completed! It provides a more standardized, predictable, expressive, safer and faster interaction with the system.
The API uses a data transfer object (DTO type) to represent a record in the system. The DTO is used to update the record. When a DTO references another object (e.g. the accession of an inventory), it will use only the basic information (Info type). This is a shorter, compact representation of the object that includes the key information, the ID and versioning information only. A DTO does not include lists of related objects (e.g. accession's inventory records). Instead, a special endpoint is sometimes available to fetch an object with detailed information (Detail type).
- A DTO never includes lists of related (child) objects.
- A DTO always references objects by their Info representation.
- An Info type never makes use of DTO types.
YandNvalues are now booleanstrueandfalse.
The endpoints use /api/v2/ (as opposed to /api/v1/) and use the following create/read/update/delete (CRUD) operations for all types of data:
| Method | Body | Response | Description |
|---|---|---|---|
POST | DTO | DTO | Register a new record in the database. The id and lastModifiedDate are automatically generated and must be used in subsequent updates. |
GET /{id} | None | DTO | Fetch a record by id from the database. |
PUT | DTO | DTO | Update an existing record. The id and lastModifiedDate (or version for some types) are required to load the current record to avoid concurrent updates of the same record by different users. The record is then updated with the information provided in the DTO. |
PUT /many | List of DTOs | List of DTOs | Allows for updating existing records with one API call. |
PUT /upsert | List of DTOs | List of DTOs | Allows for inserting or updating multiple records with one API call. |
DELETE /{id} | None | DTO | Find the record by id and remove it from the database. |
DELETE /many | List of DTOs | List of DTOs | Removes the records specified in the request body with one API call. |
GET /list | None | Page of DTOs | Available only on the most basic endpoints as it has no support for filtering the data. |
POST /list | Filter | Page of DTOs | Allows for retrieving lists of DTOs that match the filters specified in the request body |
POST /filter | Filter | Page of DTOs | Similar to above, but it generates a unique filter code to represent the filter. The code can be used in follow-up requests to invoke the same filter. |
Business logic endpoints also use DTO/Info/Detail approach. See API v2 for the details.
Please note that the endpoints in the /api/v1/ namespace are deprecated, will receive only bug fixes and no new functionality, and will be removed in the next major release.
Please switch to API v2.
Updated permission system
Security in GGCE is oriented around activity areas (e.g. passport data or seed viability) and users must be granted permissions to be able to interact with the system.
Until now, all users could read (but not necessarily change) data for all sites. 2025.1.0 requires that users are explicitly granted the permission to read data, and GGCE will show only the records from those sites where the read permission is given. This change allows you to configure GGCE so that some users see only the data for site A, some only for site B, some for both, or not at all.
To ease the transition and keep the behavior consistent with previous GGCE versions, the upgrade to this version automatically grants users the read permission. The Administrator can revoke it and configure the desired behavior.
Distribution
You can filter for requests that have specific accessions. We added more columns to the table of requested items and added customizable sorting. Before this release, the items were always sorted by their item number and you could reorganize them manually.
Administrators are able to remove a withdrawn inventory (if created by mistake), but otherwise keep the requested item as is.