Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Add x-koha-embed parameter to GET /deleted/biblios/{biblio_id} and use
$c->objects->to_api() to properly handle embedding items.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The restore functionality is a cataloguing operation and should live
under the editcatalogue permission module (bit 9) rather than tools
(bit 13), consistent with where it appears in the UI.
Update all references:
- userpermissions.sql and atomicupdate: module_bit 13 → 9
- Swagger x-koha-authorization: tools → editcatalogue
- CGI flagsrequired: tools → editcatalogue
- Templates: CAN_user_tools_records_restore → CAN_user_editcatalogue_records_restore
- C4::Auth::get_cataloguing_page_permissions: remove from tools
sub-perms list (editcatalogue '*' already covers it)
- Tests: module_bit 13 → 9
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new API endpoint to retrieve the search field
mappings configuration (search fields and their MARC mappings, grouped
by index).
The endpoint supports content negotiation:
- application/json (default)
- application/yaml (for export/import compatibility)
An optional 'type' query parameter allows filtering mappings by MARC
type (marc21 or unimarc).
Implementation notes:
- New controller: Koha::REST::V1::Config::SearchMappings
- Reuses Koha::SearchEngine::Elasticsearch::raw_elasticsearch_mappings
- Registers 'application/yaml' MIME type in Koha::REST::V1
- Permission: manage_search_engine_config
To test:
1. Apply this patch
2. Rebuild the API bundle:
$ yarn api:bundle
3. Restart Plack
4. Run:
$ prove t/db_dependent/api/v1/config_search_mappings.t
=> SUCCESS: Tests pass
5. Test manually:
$ curl -u user:pass /api/v1/config/search_mappings
=> SUCCESS: Returns JSON with search field mappings
$ curl -u user:pass -H 'Accept: application/yaml' \
/api/v1/config/search_mappings
=> SUCCESS: Returns YAML output
$ curl -u user:pass /api/v1/config/search_mappings?type=marc21
=> SUCCESS: Only marc21 mappings are returned
6. Sign off :-D
Signed-off-by: Laurence <laurence.rault@biblibre.com>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds new overrides opac_reg_yes and opac_reg_no to the patrons api
and will send a notice to the library when a patron is registered via the API if the pref is
active and the NO override is not sent, or the YES override is sent
To test:
1 - Apply patches
2 - yarn build
3 - restart_all
4 - run unit tests
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This new route will be used in a follow-up bug to auto-complete
sysprefs when using the header to search for sysprefs.
Note that this is based on top of bug 41834 that NULL options,
explanation and type in DB, but a future enhancement will populate the
response to return the values present in the yaml files.
Test plan:
1. Bundle the swagger specs and reload plack:
yarn api:bundle && koha-plack --reload kohadev
2. Fetch the sysprefs using the new route:
curl -u koha:koha --request GET 'http://${INSTANCE}-intra.localhost/api/v1/sysprefs' --header "Content-Type: application/json" | jq
3. Confirm that the tests pass
prove t/db_dependent/api/v1/sysprefs.t
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
* Add Cypress tests to cover the 404 redirect if the pref is disabled
* Add "invoices" as possible embed option for
/acquisitions/vendors/:vendor_id
Seems relevant as the api def for invoice if expecting for it
api/v1/swagger/definitions/invoice.yaml
* Tell insertObject how to generate an invoice and return it.
Unfortunately we don't have a direct route for that, hence the embed
on /vendors/:vendor_id
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This also includes a 'manager' accessor which returns the Koha::Patron
object
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Required to get users filtered by 'ill' permission for patron search modal
prove t/db_dependent/api/v1/ill_users.t
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This patch moves hardcoded source filter from 'MARC overlay rules' (batchmod, intranet, z3950, staged import, bulk import, import_lexile) to 'Record Sources' and makes them untouchable. They cannot be renamed or modified.
New record sources can be added and modified though.
All default and newly created record sources are available as filter for the module "Source" in 'MARC overlay rules'.
The API route for PUT /biblios/:biblio_id now checks for a given header x-record-source-id.
If an id is given the name of the rule is retrieved and forwarded as an overlay_context to ModBiblio.
If no id is given the fallback '*' is added as overlay_context.
Also the record source id is getting saved.
Test plan:
pre) run perl installer/data/mysql/updatedatabase.pl to add new is_system column
pre) run dbic to build Koha::Schema::Result::RecordSource as it gets a new columns is_system
pre) run 'redocly bundle --ext json api/v1/swagger/swagger.yaml --output api/v1/swagger/swagger_bundle.json' or 'yarn build'
a) enable system preference MARCOverlayRules and RESTBasicAuth
b) create new record source in /cgi-bin/koha/admin/record_sources and recognize its <NAME> and <ID>
c) create overlay rules in /cgi-bin/koha/admin/marc-overlay-rules.pl
f.e.
+----+-----+--------+----------+-----------+
| id | tag | module | filter | preset |
+----+-----+--------+----------+-----------+
| 1 | 245 | source | * | protect |
+----+-----+--------+----------+-----------+
This will make the 245 field protected from change, unless the record source matches
d) go to /cgi-bin/koha/catalogue/detail.pl?biblionumber=262 and change 245 (title) via edit -> edit record
e) save and take a look the title is still the same
f) run the updateBiblio-Request from below with a API-testing client like REST Client
g) check that title gets overwritten even though it is protected. This is due the fact the updateBiblio is not setting an overlay context.
h) apply patch
redo d) and e)
i) add another overlay rule allowing your record source to change 245:
+----+-----+--------+----------+-----------+
| id | tag | module | filter | preset |
+----+-----+--------+----------+-----------+
| 1 | 245 | source | * | protect |
| 2 | 245 | source | <NAME> | overwrite |
+----+-----+--------+----------+-----------+
j) run the updateBiblio-Request from below, be sure to fill out x-record-source-id:with your ID from step b)
k) check that title gets overwritten
l) run the updateBiblio-Request from below, but omit x-record-source-id or set it to another value than <ID>
m) check that title is not overwritten
PUT http://main-intra.localhost/api/v1/biblios/262
Authorization: Basic koha:koha
Authorization: Basic koha:koha
Content-Type: application/marcxml+xml
x-record-source-id: <ID>
<?xml version="1.0" encoding="UTF-8"?>
<record
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.loc.gov/MARC21/slimhttp://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"
xmlns="http://www.loc.gov/MARC21/slim">
<leader>01075cam a2200313 a 4500</leader>
<controlfield tag="001">foo</controlfield>
<controlfield tag="005">20200421093825.0</controlfield>
<controlfield tag="008">120417s2012 ch a b 001 0 eng </controlfield>
<datafield tag="040" ind1=" " ind2=" ">
<subfield code="c">482</subfield>
</datafield>
<datafield tag="100" ind1="1" ind2=" ">
<subfield code="a">Christiansen, Tom.</subfield>
<subfield code="9">482</subfield>
</datafield>
<datafield tag="245" ind1="1" ind2="0">
<subfield code="a">New Title</subfield>
<subfield code="c">Tom Christiansen, Brian D. Foy & Larry Wall.</subfield>
</datafield>
<datafield tag="260" ind1=" " ind2=" ">
<subfield code="a">City</subfield>
</datafield>
<datafield tag="300" ind1=" " ind2=" ">
<subfield code="a">Pages and more</subfield>
</datafield>
<datafield tag="942" ind1=" " ind2=" ">
<subfield code="c">BKS</subfield>
</datafield>
</record>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This changes the structure of record source with an is_system column which controls whether this value can be deleted.
Also predefined values are inserted to reflect the default hard coded values from 'Record overlay rules' sources
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Adds a new REST API endpoint to retrieve Koha version information.
This implementation includes:
- Koha::Status class for instance status information
- /status/version endpoint returning structured version data
- OpenAPI specification with koha_version definition
- REST controller for handling the endpoint
The returned version object includes:
- version: full version string (e.g., '25.06.00.029')
- major: major version number
- minor: minor version number
- release: major.minor version
- maintenance: major.minor.maintenance version
- development: development version (if applicable)
This prepares the foundation for a future /status endpoint that will
include all information displayed in the about page.
To test:
1. Apply the patch
2. Run:
$ ktd --shell
k$ yarn api:bundle
3. Run the tests:
k$ prove t/Koha/Status.t \
t/db_dependent/api/v1/status.t
=> SUCCESS: Tests pass!
4. Sign off :-D
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This commit adds support for the AllowFineOverrideRenewing functionality
to the REST API renewal endpoints using the standard x-koha-override pattern.
Changes:
1. Added x-koha-override header parameter to both renewal endpoints:
- POST /checkouts/{checkout_id}/renewal
- POST /checkouts/{checkout_id}/renewals
2. Updated Koha::REST::V1::Checkouts::renew() to:
- Check for 'debt_limit' in the overrides stash
- Check AllowFineOverrideRenewing preference when override is requested
- Allow renewal override only when both:
* x-koha-override header contains 'debt_limit' AND
* AllowFineOverrideRenewing preference is enabled
- Follows the established x-koha-override pattern used by other endpoints
3. Updated OpenAPI specification (swagger) to document the new header
using the standard pattern with enum values
Usage:
curl -X POST /api/v1/checkouts/123/renewal \
-H "x-koha-override: debt_limit"
The override only works for too_much_owing errors and requires
the AllowFineOverrideRenewing system preference to be enabled.
This implementation follows the same pattern as holds and other
endpoints that support overrides, maintaining consistency across
the REST API.
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
This patch uses the REST API to populate the holds table
Test plan:
1) Apply the patch
2) Go to a record with holds
3) Check that the holds table is populated correctly
4) Check that hold tables functions work correctly
5) Change HoldsSplitQueue and HoldsSplitQueueNumbering system preference, try all variations
6) Repeat steps 3 and 4
7) Search for records and place holds to multiple records
8) Repeat steps 3 and 4
9) Try with lesser permissions
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Schema type [array,object] is not valid in OpenAPI version 2.
There are two different CSP reporting directives.
One is the now deprecated "report-uri" directive. Browsers typically send a single
JSON object following the CSP2 specification.
"report-uri" is deprecated in CSP3 in favor of the newer "report-to" directive. It
is expected to contain an array of report objects.
There are browser that do not yet support the "report-to" directive, so both
directives should be supported.
There are also variations among the "report-uri" format. See
https://www.tollmanz.com/content-security-policy-report-samples/
Because of these variations, it becomes quite complex to handle the most common
cases in a single API endpoint.
We could build two separate endpoints for both directives.
Or we can accept any type of input and handle the variations in a single endpoint.
This patch attempts to do that.
Before this patch input parameters were validated by JSON::Validator. That is the
normal and recommended way to build OpenAPI endpoints in Koha. After this patch we
remove all input parameter restrictions from the OpenAPI spec, and simply accept
any type of body.
This means the controller will now always return a HTTP 204 regardless of the type
of data passed to the controller. It instead truncates too long input before
writing them into log files.
As this is not an endpoint that developers will build new Koha clients for, we
do not have to offer a very in-depth input parameter spec for this endpoint.
To test:
1. t/db_dependent/api/v1/public/csp_reports.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
[FAIL] api/v1/swagger/definitions/csp_report.yaml
FAIL new_line_at_the_end_of_file
Missing new line at the end of file, make sure your editor correctly reads .editorconfig ('insert_final_newline = true'). See bug 40541.
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch attempts to set some sane input limits to the CSP violation report.
To test:
1. Rebuild API
redocly bundle --ext json api/v1/swagger/swagger.yaml --output api/v1/swagger/swagger_bundle.json
2. t/db_dependent/api/v1/public/csp_reports.t
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add /api/v1/public/csp-reports endpoint to receive and log
Content-Security-Policy violation reports from browsers.
When CSP is configured with a report-uri directive pointing to this
endpoint, browsers will POST violation reports whenever a CSP rule
is violated. These reports are logged using Koha's logging system
for administrator review.
Features:
- Public endpoint (no authentication required, as browsers send
these reports automatically)
- Logs violations at WARN level with key details (violated directive,
blocked URI, document URI, source location)
- Logs full report at DEBUG level for detailed analysis
- Accepts both application/csp-report and application/json content types
Configuration example (in koha-conf.xml csp_header_value):
...; report-uri /api/v1/public/csp-reports
Log4perl configuration to capture CSP violations:
log4perl.logger.api.csp = WARN, CSP
log4perl.appender.CSP = Log::Log4perl::Appender::File
log4perl.appender.CSP.filename = /var/log/koha/csp-violations.log
log4perl.appender.CSP.layout = PatternLayout
log4perl.appender.CSP.layout.ConversionPattern = [%d] %m%n
Also updates koha-conf.xml documentation with CSP configuration guidance.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch prevents deletion of items that have item level holds on
them.
Test plan:
1. Create an item level hold.
2. Delete the item using alternative A or B:
A. Open the biblios Detail-view -> From the toolbar, open
"Edit"-dropdown menu -> Manage items -> Delete the item that has
an item level hold attached to it from "Actions"-dropdown menu
B. Open the biblios Detail-view -> Select the item that has an item
level hold attached to it -> Click "Delete selected items" ->
Confirm deletion
3. Notice that the item is deleted without any warning and the item
level hold has disappeared.
4. Apply this patch.
5. Repeat steps 1-3.
6. Notice that the item cannot be deleted and a warning is shown.
7. prove t/db_dependent/Koha/Item.t
8. Run the REST API tests: prove t/db_dependent/api/v1/items.t
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch implements an algorithm for selecting the item that would
leave the largest gap after the proposed booking to maximize the
opportunity for future bookings.
Key Changes:
Koha::Booking:
- Added set_itemtype_filter() method for transient itemtype parameter
- Added _select_optimal_item() method using single aggregated query
* Groups bookings by item_id with MIN(start_date)
* Selects items with no future bookings (optimal)
* Among items with bookings, selects one with latest next booking
* O(1) complexity - single database query with GROUP BY
- Updated _assign_item_for_booking() to use optimal selection
* Filters by itemtype when itemtype_id is provided
* Replaces previous random selection (RAND())
API Changes:
- Added itemtype_id parameter support to add() endpoint
- Added itemtype_id parameter support to update() endpoint
- Validates exactly one of item_id or itemtype_id is provided
- itemtype_id is transient - not persisted to database
- Extracted and applied via set_itemtype_filter() before store()
Architecture:
- itemtype_id is NOT a database column (transient only)
- Used as selection criterion, then discarded
Test plan:
1. Apply patch and restart services
2. Create "any item" booking via staff interface
3. Verify item with longest future availability is selected
4. Test via API with itemtype_id parameter
5. Verify itemtype_id is not persisted to database
6. Run t/db_dependent/Koha/Booking.t
7. Run t/db_dependent/api/v1/bookings.t
Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch enables additional fields functionality for agreement periods
in the ERM (Electronic Resource Management) module, allowing libraries
to define custom metadata fields for agreement period records.
Changes include:
- Update Koha::AdditionalField to support erm_agreement_periods table
- Modify API definitions to include extended_attributes in responses
- Add erm_agreement_periods option to additional fields admin interface
- Enhance Vue components to display and manage additional field values
- Update ShowElement component to handle period-specific attributes
Test plan:
1. Navigate to Administration > Additional fields
2. Create new fields for "Agreement periods"
3. Edit an ERM agreement and add/edit period information
4. Verify additional fields appear and can be populated
5. Confirm values are saved and displayed correctly
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the swaager definition to have the correct format
To test:
1 - Enable issue notes: AllowCheckoutNotes preference
2 - Issue an item to a patron
3 - Sign in to opac as that patron, add a note
4 - Have staff client open and a second tab try:
http://localhost:8081/api/v1/checkouts/
5 - Error "message":"Does not match date format.","path":"\/body\/0\/note_date"
6 - Apply patch, yarn build, restart all
7 - Refresh the page
8 - Success!
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch extends the additional fields framework to ERM e-holdings
titles, allowing libraries to configure custom metadata fields for
managing electronic resources.
Implementation details:
- Extended Koha::ERM::EHoldings::Title and ::Titles with
AdditionalFields mixin for object-level support
- Added 'erm_titles' table mapping to AdditionalField.pm for API
serialization
- Updated OpenAPI schema definitions to include extended_attributes
in erm_eholdings_title.yaml and expose extended_attribute_types
endpoint
- Enhanced REST API controller to handle additional fields in title
creation/updates
- Updated admin interface to allow configuring additional fields for
the 'title' table name
- Modified Vue.js EHoldingsLocalTitleResource component to display
and manage custom fields
This enables institutions to track custom metadata (e.g., license
details, administrative notes, local identifiers) alongside standard
ERM title information.
Test plan:
1. Configure additional fields:
- Go to Administration > Additional fields
- Click "New field" and select table name "title"
- Create a text field: Name="License notes", Searchable=Yes
- Create an authorized value field: Name="Access level",
AV category=LOC (or any available category)
- Save both fields
2. Test with local ERM titles:
- Navigate to E-resource management > Local titles
- Create a new local title or edit an existing one
- Verify the "Additional fields" section appears with your
configured fields
- Fill in "License notes" with test text
- Select a value for "Access level"
- Save the title
3. Verify persistence:
- Reopen the title you just edited
- Confirm both additional field values are displayed correctly
- Edit one field value and save
- Confirm the update persists
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Example usage:
POST /api/v1/acquisitions/baskets
{
"vendor_id": 1,
"name": "Basket #1",
}
Test plan:
1. Try requesting this endpoint with your favorite API tool
(I recommend https://github.com/frigus02/RESTer)
2. Run `prove t/db_dependent/api/v1/acquisitions_baskets/post.t`
Edit (tcohen): Re-did the commit with some fixes in the spec
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds the primary_contact_method field to the api response for patrons
To test:
1 - GET http://localhost:8081/api/v1/patrons/51
2 - Look for primary_contact_method, it's not there
3 - Apply patch
4 - GET http://localhost:8081/api/v1/patrons/51
5 - Look for primary_contact_method, it's not there
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Required for the follow-up ERMCounts widget
Sponsored-by: UKHSA (UK Health Security Agency)
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Following what has been done on bug 38262 we need a separate endpoint to
retrieve additional fields for vendors.
We add another proxy for acquisition in acquisition-api-client: we do
not want to retrieve all the fields for acquisition as we have more
granular permissions than ERM.
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Updates the OpenAPI definitions to support additional fields on vendor
records.
This adds:
- extended_attributes array field to vendor schema definition
- _strings field for localized/computed string representations
- extended_attributes and +strings to available embed options
These changes allow the API to expose and accept additional field data
when retrieving or modifying vendor records via the REST API.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Kyle M Hall
Jacob O'Mara
Martin Renvoize
Tomás Cohen Arazi
Nick Clemens
Jonathan Druart
Pedro Amorim
Jan Kissig
Johanna Räisä
Lari Taskula
David Cook
Olli Kautonen
Lucas Gass
Andrew Fuerste Henry
Matt Blenkinsop
Matt Blenkinsop
Julian Maurice
Alexis Ripetti
Pedro Amorim