From e7d0269f160bbfa1f9e2dcf6a2d5784643b9bef1 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Fri, 7 Nov 2025 16:56:03 +0000 Subject: [PATCH 1/8] Adjust some rst roles away from :property: to :field: --- optimade.rst | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/optimade.rst b/optimade.rst index 45c5443c6..559472ec2 100644 --- a/optimade.rst +++ b/optimade.rst @@ -69,6 +69,8 @@ OPTIMADE API specification v1.3.0-rc.1 .. role:: type(literal) +.. role:: property-example(literal) + .. role:: property-fail(literal) .. role:: endpoint(literal) @@ -1321,7 +1323,7 @@ The API implementation MAY provide other entry types than the ones standardized Such entry types MUST be prefixed by a database-provider-specific prefix (i.e., the resource objects' :property:`type` value should start with the database-provider-specific prefix, e.g., :property:`type` = :val:`_exmpl_workflows`). Each custom entry type SHOULD be served at a corresponding entry listing endpoint under the versioned or unversioned base URL that serves the API with the same name (i.e., equal to the resource objects' :property:`type` value, e.g., :endpoint:`/_exmpl_workflows`). It is RECOMMENDED to align with the OPTIMADE API specification practice of using a plural for entry resource types and entry type endpoints. -Any custom entry listing endpoint MUST also be added to the :property:`available_endpoints` and :property:`entry_types_by_format` attributes of the `Base Info Endpoint`_. +Any custom entry listing endpoint MUST also be added to the :field:`available_endpoints` and :field:`entry_types_by_format` attributes of the `Base Info Endpoint`_. For more on custom endpoints, see `Custom Extension Endpoints`_. @@ -1870,9 +1872,9 @@ The links endpoint MUST be provided under the versioned or unversioned base URL Link Types ~~~~~~~~~~ -Each link has a :property:`link_type` attribute that specifies the type of the linked relation. +Each link has a :field:`link_type` attribute that specifies the type of the linked relation. -The :property:`link_type` MUST be one of the following values: +The :field:`link_type` MUST be one of the following values: - :field-val:`child`: a link to another OPTIMADE implementation that MUST be within the same provider. This allows the creation of a tree-like structure of databases by pointing to children sub-databases. @@ -1914,17 +1916,17 @@ The resource objects' response dictionaries MUST include the following fields: - **link\_type**: a string containing the link type. It MUST be one of the values listed above in section `Link Types`_. - - **aggregate**: a string indicating whether a client that is following links to aggregate results from different OPTIMADE implementations should follow this link or not. This flag SHOULD NOT be indicated for links where :property:`link_type` is not :val:`child`. + - **aggregate**: a string indicating whether a client that is following links to aggregate results from different OPTIMADE implementations should follow this link or not. This flag SHOULD NOT be indicated for links where :field:`link_type` is not :val:`child`. If not specified, clients MAY assume that the value is :val:`ok`. If specified, and the value is anything different than :val:`ok`, the client MUST assume that the server is suggesting not to follow the link during aggregation by default (also if the value is not among the known ones, in case a future specification adds new accepted values). Specific values indicate the reason why the server is providing the suggestion. - A client MAY follow the link anyway if it has reason to do so (e.g., if the client is looking for all test databases, it MAY follow the links where :property:`aggregate` has value :val:`test`). + A client MAY follow the link anyway if it has reason to do so (e.g., if the client is looking for all test databases, it MAY follow the links where :field:`aggregate` has value :val:`test`). If specified, it MUST be one of the values listed in section `Link Aggregate Options`_. - - **no_aggregate_reason**: an OPTIONAL human-readable string indicating the reason for suggesting not to aggregate results following the link. It SHOULD NOT be present if :property:`aggregate` has value :val:`ok`. + - **no_aggregate_reason**: an OPTIONAL human-readable string indicating the reason for suggesting not to aggregate results following the link. It SHOULD NOT be present if :field:`aggregate` has value :val:`ok`. Example: @@ -2023,11 +2025,11 @@ Example: Internal Links: Root and Child Links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Any number of resource objects with :property:`link_type` equal to :val:`child` MAY be present as part of the :field:`data` list. +Any number of resource objects with :field:`link_type` equal to :val:`child` MAY be present as part of the :field:`data` list. A :val:`child` object represents a "link" to an OPTIMADE implementation within the same provider exactly one layer **below** the current implementation's layer. -Exactly one resource object with :property:`link_type` equal to :val:`root` MUST be present as part of the :field:`data` list. -Note: the same implementation may of course be linked by other implementations via a :endpoint:`/links` endpoint with :property:`link_type` equal to :val:`external`. +Exactly one resource object with :field:`link_type` equal to :val:`root` MUST be present as part of the :field:`data` list. +Note: the same implementation may of course be linked by other implementations via a :endpoint:`/links` endpoint with :field:`link_type` equal to :val:`external`. The :val:`root` resource object represents a link to the topmost OPTIMADE implementation of the current provider. By following :val:`child` links from the :val:`root` object recursively, it MUST be possible to reach the current OPTIMADE implementation. @@ -2038,7 +2040,7 @@ In practice, this forms a tree structure for the OPTIMADE implementations of a p List of Providers Links ~~~~~~~~~~~~~~~~~~~~~~~ -Resource objects with :property:`link_type` equal to :val:`providers` MUST point to an `Index Meta-Database`_ that supplies a list of OPTIMADE database providers. +Resource objects with :field:`link_type` equal to :val:`providers` MUST point to an `Index Meta-Database`_ that supplies a list of OPTIMADE database providers. The intention is to be able to auto-discover all providers of OPTIMADE implementations. A list of known database providers can be retrieved as described in section `Namespace Prefixes`_. @@ -2054,12 +2056,12 @@ This will make all OPTIMADE databases and implementations by the provider discov Link Aggregate Options ~~~~~~~~~~~~~~~~~~~~~~ -If specified, the :property:`aggregate` attributed MUST have one of the following values: +If specified, the :field:`aggregate` attributed MUST have one of the following values: - :val:`ok` (default value, if unspecified): it is ok to follow this link when aggregating OPTIMADE results. - :val:`test`: the linked database is a test database, whose content might not be correct or might not represent physically-meaningful data. Therefore by default the link should not be followed. - :val:`staging`: the linked database is almost production-ready, but final checks on its content are being performed, so the content might still contain errors. Therefore by default the link should not be followed. -- :val:`no`: any other reason to suggest not to follow the link during aggregation of OPTIMADE results. The implementation MAY provide mode details in a human-readable form via the attribute :property:`no-aggregate-reason`. +- :val:`no`: any other reason to suggest not to follow the link during aggregation of OPTIMADE results. The implementation MAY provide mode details in a human-readable form via the attribute :field:`no_aggregate_reason`. Custom Extension Endpoints -------------------------- @@ -2100,9 +2102,9 @@ The following tokens are used in the filter query component: Examples of valid property names: - - :property:`band_gap` - - :property:`cell_length_a` - - :property:`cell_volume` + - :property-example:`band_gap` + - :property-example:`cell_length_a` + - :property-example:`cell_volume` Examples of incorrect property names: @@ -4401,7 +4403,7 @@ checksums - **Support**: OPTIONAL support in implementations, i.e., MAY be :val:`null`. - **Query**: Support for queries on this property is OPTIONAL. - - Supported dictionary keys: :property:`md5`, :property:`sha1`, :property:`sha224`, :property:`sha256`, :property:`sha384`, :property:`sha512`. + - Supported dictionary keys: :field:`md5`, :field:`sha1`, :field:`sha224`, :field:`sha256`, :field:`sha384`, :field:`sha512`. Checksums outside this list MAY be used, but their names MUST be prefixed by a database-provider-specific namespace prefix (see appendix `Namespace Prefixes`_). atime From 4c6b62d2718f3b9736ca496f420baacca46bfb3a Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Sun, 16 Nov 2025 13:46:10 +0000 Subject: [PATCH 2/8] Add property definition checker to audit system MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit adds scripts to verify that all properties defined in the specification (optimade.rst) have corresponding schema definition files. - extract_entry_fields.sh: Extracts field names from the Entry List section of optimade.rst, looking for properties with ~~~~ underlines - check_property_definitions.sh: Compares extracted fields against schema definitions in schemas/src/defs/, reporting missing definitions and orphaned schema files - Updated Makelocal-audit to include audit_property_definitions target in the main audit suite The checker validates that: 1. All properties with ~~~~ formatting have corresponding YAML schema files 2. Common properties exist in the core/ directory 3. Entry-specific properties exist in the appropriate optimade// directories 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- tests/makefiles/Makelocal-audit | 8 +- tests/scripts/check_property_definitions.sh | 161 ++++++++++++++++++++ tests/scripts/extract_entry_fields.sh | 95 ++++++++++++ 3 files changed, 263 insertions(+), 1 deletion(-) create mode 100755 tests/scripts/check_property_definitions.sh create mode 100755 tests/scripts/extract_entry_fields.sh diff --git a/tests/makefiles/Makelocal-audit b/tests/makefiles/Makelocal-audit index ed0982a42..4f9ca12cc 100644 --- a/tests/makefiles/Makelocal-audit +++ b/tests/makefiles/Makelocal-audit @@ -4,7 +4,7 @@ .PHONY: audit -audit: audit_grammars audit_authors audit_spelling audit_schemas +audit: audit_grammars audit_authors audit_spelling audit_schemas audit_property_definitions @echo "==============================================" @echo "Audit of specification completed successfully." @echo "==============================================" @@ -35,3 +35,9 @@ audit_spelling: audit_schemas: $(MAKE) validate_schemas + + +.PHONY: audit_property_definitions + +audit_property_definitions: + tests/scripts/check_property_definitions.sh diff --git a/tests/scripts/check_property_definitions.sh b/tests/scripts/check_property_definitions.sh new file mode 100755 index 000000000..b8beac5e4 --- /dev/null +++ b/tests/scripts/check_property_definitions.sh @@ -0,0 +1,161 @@ +#!/bin/bash +# Script to verify that all properties in the specification have corresponding schema definitions +# Compares fields extracted from optimade.rst with schema definition files + +set -euo pipefail + +# Colors for output +RED='\033[0;31m' +GREEN='\033[0;32m' +YELLOW='\033[0;33m' +NC='\033[0m' # No Color + +# Extract fields from specification +spec_fields=$(tests/scripts/extract_entry_fields.sh) + +# Track errors +errors=0 +warnings=0 + +echo "Checking property definitions against specification..." +echo "" + +# Function to check if a property definition file exists +check_property() { + local entry_type=$1 + local property=$2 + local version=${3:-v1.2} # Default to v1.2 + + # Check in the main entry type directory first + local primary_path="schemas/src/defs/$version/properties/optimade/$entry_type/$property.yaml" + + # Also check v1.3 for newer properties + local v13_path="schemas/src/defs/v1.3/properties/optimade/$entry_type/$property.yaml" + + # Check core properties (shared across types) + local core_path="schemas/src/defs/$version/properties/core/$property.yaml" + + if [[ -f "$primary_path" ]] || [[ -f "$v13_path" ]] || [[ -f "$core_path" ]]; then + return 0 + else + return 1 + fi +} + +# Get the entry types from the JSON output +entry_types=$(echo "$spec_fields" | jq -r 'keys[]') + +for entry_type in $entry_types; do + echo "Checking $entry_type..." + + # Special handling for _common (these should be in core/) + if [[ "$entry_type" == "_common" ]]; then + properties=$(echo "$spec_fields" | jq -r '.["_common"][]') + for property in $properties; do + # Common properties should exist in core/ or be shared + if [[ -f "schemas/src/defs/v1.2/properties/core/$property.yaml" ]]; then + echo -e " ${GREEN}✓${NC} $property (core)" + else + # Check if it exists in any entry type + found=false + for et in structures files references calculations; do + if check_property "$et" "$property"; then + echo -e " ${GREEN}✓${NC} $property (in $et)" + found=true + break + fi + done + if [[ "$found" == "false" ]]; then + echo -e " ${RED}✗${NC} $property - MISSING" + ((errors++)) + fi + fi + done + else + properties=$(echo "$spec_fields" | jq -r --arg et "$entry_type" '.[$et][]') + + # Skip if no properties (empty array) - this is OK for some entry types like calculations + if [[ -z "$properties" ]]; then + echo -e " No specific properties with ~~~~ underlines (uses common properties only)" + continue + fi + + for property in $properties; do + if check_property "$entry_type" "$property"; then + echo -e " ${GREEN}✓${NC} $property" + else + # Special case: references properties are defined but not with ~~~~ in spec + if [[ "$entry_type" == "references" ]]; then + # References are documented differently, check if the file exists anyway + if [[ -f "schemas/src/defs/v1.2/properties/optimade/references/$property.yaml" ]]; then + echo -e " ${GREEN}✓${NC} $property" + else + echo -e " ${RED}✗${NC} $property - MISSING" + ((errors++)) + fi + else + echo -e " ${RED}✗${NC} $property - MISSING" + ((errors++)) + fi + fi + done + fi + echo "" +done + +# Also check for orphaned schema files (schemas without spec entries) +echo "Checking for properties defined in schemas but not in specification..." +echo "" + +for entry_type in structures files references calculations trajectories; do + schema_dir="schemas/src/defs/v1.2/properties/optimade/$entry_type" + + if [[ ! -d "$schema_dir" ]]; then + # Check v1.3 + schema_dir="schemas/src/defs/v1.3/properties/optimade/$entry_type" + if [[ ! -d "$schema_dir" ]]; then + continue + fi + fi + + # Get properties from spec for this entry type + if [[ "$entry_type" == "trajectories" ]]; then + spec_props=$(echo "$spec_fields" | jq -r '.trajectories[]?' 2>/dev/null || echo "") + else + spec_props=$(echo "$spec_fields" | jq -r --arg et "$entry_type" '.[$et][]?' 2>/dev/null || echo "") + fi + + # Also include common properties + common_props=$(echo "$spec_fields" | jq -r '._common[]?' 2>/dev/null || echo "") + all_spec_props=$(echo -e "$spec_props\n$common_props" | sort | uniq) + + # Find all schema files + for schema_file in "$schema_dir"/*.yaml; do + if [[ ! -f "$schema_file" ]]; then + continue + fi + + property=$(basename "$schema_file" .yaml) + + # Check if this property is in the spec + if echo "$all_spec_props" | grep -q "^${property}$"; then + : # Found, nothing to do + else + echo -e " ${YELLOW}⚠${NC} $entry_type/$property - Schema exists but not in specification (or uses different formatting)" + ((warnings++)) + fi + done +done + +echo "" +echo "==============================================" +echo "Summary:" +echo " Errors: $errors" +echo " Warnings: $warnings" +echo "==============================================" + +if [[ $errors -gt 0 ]]; then + exit 1 +else + exit 0 +fi diff --git a/tests/scripts/extract_entry_fields.sh b/tests/scripts/extract_entry_fields.sh new file mode 100755 index 000000000..61eff9586 --- /dev/null +++ b/tests/scripts/extract_entry_fields.sh @@ -0,0 +1,95 @@ +#!/bin/bash +# Script to extract field names from optimade.rst Entry List section +# Extracts properties with ~~~~ underlines and groups by entry type + +set -euo pipefail + +input_file="optimade.rst" + +if [[ ! -f "$input_file" ]]; then + echo "Error: $input_file not found" >&2 + exit 1 +fi + +# Use awk to process the entire file +awk ' +BEGIN { + in_entry_list = 0 + in_section = 0 + current_section = "" + prev_line = "" + print "{" + first_section = 1 +} + +# Detect "Entry List" section start +/^Entry List$/ { + getline # Read the ===== line + in_entry_list = 1 + next +} + +# Exit Entry List section when we hit another major section (with ======) +in_entry_list && /^=+$/ && prev_line !~ /^Entry List$/ { + in_entry_list = 0 +} + +# Detect "Properties Used by Multiple Entry Types" +in_entry_list && /^Properties Used by Multiple Entry Types$/ { + if (in_section) { + print " ]," + } else if (!first_section) { + print "," + } + print " \"_common\": [" + current_section = "_common" + in_section = 1 + first_section = 0 + first_field = 1 + next +} + +# Detect entry type sections (e.g., "Structures Entries") +in_entry_list && /^[A-Z][a-z]+ Entries$/ { + if (in_section) { + print "" + print " ]," + } else if (!first_section) { + print "," + } + # Extract entry type name and convert to lowercase + entry_type = tolower($1) + printf " \"%s\": [\n", entry_type + current_section = entry_type + in_section = 1 + first_section = 0 + first_field = 1 + next +} + +# Detect field names (lines with ~~~~ underneath) +in_section && /^~+$/ && prev_line ~ /^[a-z_][a-z_0-9\\]*$/ { + # prev_line contains the field name + if (!first_field) { + print "," + } + # Handle escaped underscores in field names + field = prev_line + gsub(/\\/, "", field) # Remove backslashes + printf " \"%s\"", field + first_field = 0 +} + +# Store current line for next iteration +{ + prev_line = $0 +} + +END { + if (in_section) { + print "" + print " ]" + } + print "}" +} +' "$input_file" From 4faaf93fa55987505b5754d1c7ec05054f059665 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Sun, 16 Nov 2025 13:54:20 +0000 Subject: [PATCH 3/8] Remove restrictive set flags to allow scripts to continue on errors The scripts now continue checking all properties and report all errors at the end, rather than exiting on the first error. --- tests/scripts/check_property_definitions.sh | 14 ++++++++++---- tests/scripts/extract_entry_fields.sh | 2 -- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/tests/scripts/check_property_definitions.sh b/tests/scripts/check_property_definitions.sh index b8beac5e4..6f1320017 100755 --- a/tests/scripts/check_property_definitions.sh +++ b/tests/scripts/check_property_definitions.sh @@ -2,8 +2,6 @@ # Script to verify that all properties in the specification have corresponding schema definitions # Compares fields extracted from optimade.rst with schema definition files -set -euo pipefail - # Colors for output RED='\033[0;31m' GREEN='\033[0;32m' @@ -141,8 +139,16 @@ for entry_type in structures files references calculations trajectories; do if echo "$all_spec_props" | grep -q "^${property}$"; then : # Found, nothing to do else - echo -e " ${YELLOW}⚠${NC} $entry_type/$property - Schema exists but not in specification (or uses different formatting)" - ((warnings++)) + if [[ "$entry_type" == "references" ]]; then + # References properties might not be in spec with ~~~~ but still valid + if grep -q "^${property}$" <<< "$spec_props"; then + echo -e " ${GREEN}✓${NC} $entry_type/$property" + continue + fi + else + echo -e " ${YELLOW}⚠${NC} $entry_type/$property - Schema exists but not in specification (or uses different formatting)" + ((warnings++)) + fi fi done done diff --git a/tests/scripts/extract_entry_fields.sh b/tests/scripts/extract_entry_fields.sh index 61eff9586..80fb6ac83 100755 --- a/tests/scripts/extract_entry_fields.sh +++ b/tests/scripts/extract_entry_fields.sh @@ -2,8 +2,6 @@ # Script to extract field names from optimade.rst Entry List section # Extracts properties with ~~~~ underlines and groups by entry type -set -euo pipefail - input_file="optimade.rst" if [[ ! -f "$input_file" ]]; then From 34887d835993693b24e80d9e4eee68252e33c8e5 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Sun, 16 Nov 2025 13:54:35 +0000 Subject: [PATCH 4/8] Add audit schemas run to CI --- .github/workflows/ci.yml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 860eb0729..6e44a5e4b 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -78,3 +78,9 @@ jobs: - name: Validate schemas run: make schemas + + - name: Validate schemas + run: make audit_schemas + + - name: Validate that all properties have schemas + run: make audit_property_definitions From 59a5ec220afc503614aaf0c230304eedd1ed5c73 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Sun, 16 Nov 2025 13:56:05 +0000 Subject: [PATCH 5/8] Linting --- .github/workflows/ci.yml | 2 +- tests/scripts/check_property_definitions.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 6e44a5e4b..dfc06c45f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -78,7 +78,7 @@ jobs: - name: Validate schemas run: make schemas - + - name: Validate schemas run: make audit_schemas diff --git a/tests/scripts/check_property_definitions.sh b/tests/scripts/check_property_definitions.sh index 6f1320017..77e4e1eaf 100755 --- a/tests/scripts/check_property_definitions.sh +++ b/tests/scripts/check_property_definitions.sh @@ -145,7 +145,7 @@ for entry_type in structures files references calculations trajectories; do echo -e " ${GREEN}✓${NC} $entry_type/$property" continue fi - else + else echo -e " ${YELLOW}⚠${NC} $entry_type/$property - Schema exists but not in specification (or uses different formatting)" ((warnings++)) fi From fb106f4bf17609308d0d3988f5972e4c9ca476f3 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Sun, 16 Nov 2025 20:40:01 +0000 Subject: [PATCH 6/8] Remove make audit_schemas --- .github/workflows/ci.yml | 3 --- 1 file changed, 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index dfc06c45f..6ff3a5082 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -79,8 +79,5 @@ jobs: - name: Validate schemas run: make schemas - - name: Validate schemas - run: make audit_schemas - - name: Validate that all properties have schemas run: make audit_property_definitions From b84a727d75d3e1268d1797582ab69406c17dc1d4 Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Mon, 17 Nov 2025 14:02:16 +0000 Subject: [PATCH 7/8] Fix CHANGELOG typo --- CHANGELOG.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 397f7fa5e..fd86529a9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,8 +11,7 @@ Minor OPTIMADE releases are always intended to be backwards-compatible for clien ## New features -- **Trajectories endpoint** ([#377](https://github.com/Materials-Consortia/OPTIMADE/pull/377), [#481](https://github.com/Materials-Consortia/OPTIMADE/pull/481)) -): A new trajectories entry type has been added to the specification to share data belonging to ordered sequences of structures, such as those arising from molecular dynamics simulations or geometry optimizations. +- **Trajectories endpoint** ([#377](https://github.com/Materials-Consortia/OPTIMADE/pull/377), [#481](https://github.com/Materials-Consortia/OPTIMADE/pull/481)): A new trajectories entry type has been added to the specification to share data belonging to ordered sequences of structures, such as those arising from molecular dynamics simulations or geometry optimizations. In order to handle large individual entries, this endpoint makes use of the partial data protocol introduced in v1.2, with additional specialisations for slicing (e.g., the `dimension_slices` URL parameter) and representing dimensions that remain constant throughout a trajectory, whilst retaining the ability to filter using the normal OPTIMADE syntax via the `reference_frame` field. - **Provider-specific data types** ([#560](https://github.com/Materials-Consortia/OPTIMADE/pull/560)): Providers and namespaces can now define custom data types for their properties that let them use specific query semantics that differ from the standard OPTIMADE data types. For example, a provider could define a field that uses a string format for a field, but a custom data type that allows for e.g., `CONTAINS` queries to do something other than pure substring matching. From e8b3f8b1fec904191383b3edc11ffb6226429dfe Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Mon, 17 Nov 2025 14:04:17 +0000 Subject: [PATCH 8/8] remove hardcoded entry type list --- tests/scripts/check_property_definitions.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/scripts/check_property_definitions.sh b/tests/scripts/check_property_definitions.sh index 77e4e1eaf..5bd51388a 100755 --- a/tests/scripts/check_property_definitions.sh +++ b/tests/scripts/check_property_definitions.sh @@ -56,7 +56,7 @@ for entry_type in $entry_types; do else # Check if it exists in any entry type found=false - for et in structures files references calculations; do + for et in $entry_types; do if check_property "$et" "$property"; then echo -e " ${GREEN}✓${NC} $property (in $et)" found=true