Extraction of common properties from schema files #1011
Conversation
Summary by CodeRabbit
WalkthroughThe changes update several JSON schema files and their associated test cases. The JSON schemas for chapters, committees, common definitions, and projects now include explicit type definitions, unique item enforcement, refined property descriptions, and updated formats. In addition, several YAML test files have been modified to reflect these schema updates. Updates include replacement of tag names, adjustments in the structure of event entries (from string URLs to objects with a Changes
Tip ⚡🧪 Multi-step agentic review comment chat (experimental)
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (96)
💤 Files with no reviewable changes (2)
🚧 Files skipped from review as they are similar to previous changes (89)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (18)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
schema/tests/common/mailing_list_test.py (1)
1-27: 💡 Verification agent🧩 Analysis chain
Verify test data files existence.
Let's verify that all the test data files referenced in the parameterized test exist and contain the expected content.
🏁 Script executed:
#!/bin/bash # Description: Verify that all test data files for mailing_list tests exist echo "Checking for mailing list test data files..." fd -p "tests/data/mailing_list/negative" # List content of test data files to verify they match the error cases for file in $(fd -p "tests/data/mailing_list/negative" -t f); do echo "Content of $file:" cat $file echo "-----------------------" done # Also check positive test files fd -p "tests/data/mailing_list/positive" -t fLength of output: 232
Action: Verify and Update Mailing List Test Data Files
The shell script output shows no files listed under both
tests/data/mailing_list/negativeandtests/data/mailing_list/positive. Please ensure that:
- The negative test files referenced in the parameterized test (i.e.
description_empty.yaml,description_null.yaml,email_empty.yaml, andemail_null.yaml) exist in the expected directory (likely undertests/data/mailing_list/negative) and that their contents match the expected error cases.- The positive test files exist in
tests/data/mailing_list/positive(or the appropriate directory) as required bycommon_positive_test.If these files have been moved or renamed, update the test file paths accordingly.
🧹 Nitpick comments (5)
schema/tests/common/tags_test.py (2)
7-7: Consider adding a docstring to the SCHEMA_NAME constant.Adding a brief docstring to the SCHEMA_NAME constant would improve code documentation by clarifying its purpose and usage in the test file.
-SCHEMA_NAME = "tag" +# Name of the schema being tested +SCHEMA_NAME = "tag"
9-10: Remove excessive blank lines.There are two consecutive blank lines here, where one would be sufficient according to PEP 8 style guidelines.
SCHEMA_NAME = "tag" - @pytest.mark.parametrize(schema/tests/data/project/negative/type_null.yaml (1)
9-10: Structured Conversion of the "name" Field
The transformation of thenameproperty from a simple string to a structured list holding avaluekey is clear and consistent. This change facilitates future extensibility for additional attributes.schema/project.json (2)
47-55: Documentation Property Array Conversion & Custom Flag Usage:
Thedocumentationproperty has been restructured into an array with a minimum item requirement and uniqueness enforced. Note the inclusion of"optional": true—please verify that this non-standard keyword is intended for your custom tooling or downstream processing, as it is not part of the official JSON Schema specification.
57-66: Downloads Property Array Conversion & Optionality Flag:
Similarly, thedownloadsproperty now expects an array of URL strings with uniqueness enforced. The addition of"optional": trueshould be reviewed to ensure it aligns with your validation logic, since it is not a standard JSON Schema keyword.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (193)
schema/chapter.json(4 hunks)schema/committee.json(5 hunks)schema/common.json(8 hunks)schema/project.json(6 hunks)schema/tests/chapter_test.py(3 hunks)schema/tests/committee_test.py(3 hunks)schema/tests/common/events_test.py(1 hunks)schema/tests/common/mailing_list_test.py(1 hunks)schema/tests/common/name_test.py(1 hunks)schema/tests/common/tags_test.py(1 hunks)schema/tests/common/website_test.py(1 hunks)schema/tests/data/chapter/negative/blog_empty.yaml(1 hunks)schema/tests/data/chapter/negative/blog_invalid.yaml(1 hunks)schema/tests/data/chapter/negative/blog_null.yaml(1 hunks)schema/tests/data/chapter/negative/community_empty.yaml(1 hunks)schema/tests/data/chapter/negative/community_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/community_null.yaml(1 hunks)schema/tests/data/chapter/negative/country_empty.yaml(1 hunks)schema/tests/data/chapter/negative/country_null.yaml(1 hunks)schema/tests/data/chapter/negative/country_undefined.yaml(1 hunks)schema/tests/data/chapter/negative/events_empty.yaml(1 hunks)schema/tests/data/chapter/negative/events_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/events_null.yaml(1 hunks)schema/tests/data/chapter/negative/leaders_empty.yaml(1 hunks)schema/tests/data/chapter/negative/leaders_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/leaders_null.yaml(1 hunks)schema/tests/data/chapter/negative/leaders_undefined.yaml(1 hunks)schema/tests/data/chapter/negative/logo_empty.yaml(1 hunks)schema/tests/data/chapter/negative/logo_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/logo_null.yaml(1 hunks)schema/tests/data/chapter/negative/meetup_group_empty.yaml(1 hunks)schema/tests/data/chapter/negative/meetup_group_null.yaml(1 hunks)schema/tests/data/chapter/negative/name_empty.yaml(1 hunks)schema/tests/data/chapter/negative/name_null.yaml(1 hunks)schema/tests/data/chapter/negative/name_undefined.yaml(1 hunks)schema/tests/data/chapter/negative/region_empty.yaml(1 hunks)schema/tests/data/chapter/negative/region_null.yaml(1 hunks)schema/tests/data/chapter/negative/social_media_empty.yaml(1 hunks)schema/tests/data/chapter/negative/social_media_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/social_media_null.yaml(1 hunks)schema/tests/data/chapter/negative/sponsors_empty.yaml(1 hunks)schema/tests/data/chapter/negative/sponsors_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/sponsors_null.yaml(1 hunks)schema/tests/data/chapter/negative/tags_empty.yaml(1 hunks)schema/tests/data/chapter/negative/tags_non_unique.yaml(1 hunks)schema/tests/data/chapter/negative/tags_null.yaml(1 hunks)schema/tests/data/chapter/negative/tags_undefined.yaml(1 hunks)schema/tests/data/chapter/negative/website_empty.yaml(1 hunks)schema/tests/data/chapter/negative/website_null.yaml(1 hunks)schema/tests/data/chapter/positive/optional_properties.yaml(3 hunks)schema/tests/data/chapter/positive/required_properties.yaml(1 hunks)schema/tests/data/committee/negative/community_empty.yaml(1 hunks)schema/tests/data/committee/negative/community_non_unique.yaml(1 hunks)schema/tests/data/committee/negative/community_null.yaml(1 hunks)schema/tests/data/committee/negative/description_null.yaml(1 hunks)schema/tests/data/committee/negative/description_undefined.yaml(1 hunks)schema/tests/data/committee/negative/events_empty.yaml(1 hunks)schema/tests/data/committee/negative/events_invalid.yaml(0 hunks)schema/tests/data/committee/negative/events_non_unique.yaml(1 hunks)schema/tests/data/committee/negative/events_null.yaml(1 hunks)schema/tests/data/committee/negative/logo_empty.yaml(1 hunks)schema/tests/data/committee/negative/logo_non_unique.yaml(1 hunks)schema/tests/data/committee/negative/logo_null.yaml(1 hunks)schema/tests/data/committee/negative/mailing_list_empty.yaml(1 hunks)schema/tests/data/committee/negative/mailing_list_null.yaml(1 hunks)schema/tests/data/committee/negative/meeting_minutes_invalid.yaml(1 hunks)schema/tests/data/committee/negative/meeting_minutes_null.yaml(1 hunks)schema/tests/data/committee/negative/members_empty.yaml(1 hunks)schema/tests/data/committee/negative/members_null.yaml(1 hunks)schema/tests/data/committee/negative/members_undefined.yaml(1 hunks)schema/tests/data/committee/negative/name_empty.yaml(1 hunks)schema/tests/data/committee/negative/name_undefined.yaml(1 hunks)schema/tests/data/committee/negative/resources_invalid.yaml(1 hunks)schema/tests/data/committee/negative/resources_null.yaml(1 hunks)schema/tests/data/committee/negative/scope_invalid.yaml(1 hunks)schema/tests/data/committee/negative/scope_null.yaml(1 hunks)schema/tests/data/committee/negative/social_media_empty.yaml(1 hunks)schema/tests/data/committee/negative/social_media_invalid.yaml(1 hunks)schema/tests/data/committee/negative/social_media_null.yaml(1 hunks)schema/tests/data/committee/negative/sponsors_empty.yaml(1 hunks)schema/tests/data/committee/negative/sponsors_invalid.yaml(1 hunks)schema/tests/data/committee/negative/sponsors_null.yaml(1 hunks)schema/tests/data/committee/negative/tags_empty.yaml(1 hunks)schema/tests/data/committee/negative/tags_null.yaml(1 hunks)schema/tests/data/committee/negative/tags_undefined.yaml(1 hunks)schema/tests/data/committee/negative/website_empty.yaml(1 hunks)schema/tests/data/committee/negative/website_null.yaml(1 hunks)schema/tests/data/committee/positive/optional_properties.yaml(3 hunks)schema/tests/data/committee/positive/required_properties.yaml(1 hunks)schema/tests/data/common/event/negative/description_empty.yaml(1 hunks)schema/tests/data/common/event/negative/description_null.yaml(1 hunks)schema/tests/data/common/event/negative/title_empty.yaml(1 hunks)schema/tests/data/common/event/negative/title_null.yaml(1 hunks)schema/tests/data/common/event/negative/title_undefined.yaml(1 hunks)schema/tests/data/common/event/negative/url_empty.yaml(1 hunks)schema/tests/data/common/event/negative/url_invalid.yaml(1 hunks)schema/tests/data/common/event/negative/url_null.yaml(1 hunks)schema/tests/data/common/event/negative/url_undefined.yaml(1 hunks)schema/tests/data/common/event/positive/optional_properties.yaml(1 hunks)schema/tests/data/common/event/positive/required_properties.yaml(1 hunks)schema/tests/data/common/mailing_list/negative/description_empty.yaml(1 hunks)schema/tests/data/common/mailing_list/negative/description_null.yaml(1 hunks)schema/tests/data/common/mailing_list/negative/email_empty.yaml(1 hunks)schema/tests/data/common/mailing_list/negative/email_null.yaml(1 hunks)schema/tests/data/common/mailing_list/positive/oprional_properties.yaml(1 hunks)schema/tests/data/common/mailing_list/positive/required_properties.yaml(1 hunks)schema/tests/data/common/name/negative/description_empty.yaml(1 hunks)schema/tests/data/common/name/negative/description_null.yaml(1 hunks)schema/tests/data/common/name/negative/name_empty.yaml(1 hunks)schema/tests/data/common/name/negative/name_null.yaml(1 hunks)schema/tests/data/common/name/positive/optional_properties.yaml(1 hunks)schema/tests/data/common/name/positive/required_properties.yaml.yaml(1 hunks)schema/tests/data/common/tag/negative/description_empty.yaml(1 hunks)schema/tests/data/common/tag/negative/description_null.yaml(1 hunks)schema/tests/data/common/tag/negative/tag_empty.yaml(1 hunks)schema/tests/data/common/tag/negative/tag_null.yaml(1 hunks)schema/tests/data/common/tag/negative/tag_undefined.yaml(1 hunks)schema/tests/data/common/tag/positive/optional_properties.yaml(1 hunks)schema/tests/data/common/tag/positive/required_properties.yaml(1 hunks)schema/tests/data/common/website/negative/description_empty.yaml(1 hunks)schema/tests/data/common/website/negative/description_null.yaml(1 hunks)schema/tests/data/common/website/negative/url_empty.yaml(1 hunks)schema/tests/data/common/website/negative/url_invalid.yaml(1 hunks)schema/tests/data/common/website/negative/url_null.yaml(1 hunks)schema/tests/data/common/website/negative/url_undefined.yaml(1 hunks)schema/tests/data/common/website/positive/optional_properties.yaml(1 hunks)schema/tests/data/common/website/positive/required_properties.yaml(1 hunks)schema/tests/data/project/negative/audience_empty.yaml(1 hunks)schema/tests/data/project/negative/audience_invalid.yaml(1 hunks)schema/tests/data/project/negative/audience_null.yaml(1 hunks)schema/tests/data/project/negative/audience_undefined.yaml(1 hunks)schema/tests/data/project/negative/blog_empty.yaml(1 hunks)schema/tests/data/project/negative/blog_invalid.yaml(1 hunks)schema/tests/data/project/negative/blog_null.yaml(1 hunks)schema/tests/data/project/negative/community_empty.yaml(1 hunks)schema/tests/data/project/negative/community_non_unique.yaml(1 hunks)schema/tests/data/project/negative/community_null.yaml(1 hunks)schema/tests/data/project/negative/demo_empty.yaml(1 hunks)schema/tests/data/project/negative/demo_invalid.yaml(1 hunks)schema/tests/data/project/negative/demo_non_unique.yaml(1 hunks)schema/tests/data/project/negative/demo_null.yaml(1 hunks)schema/tests/data/project/negative/documentation_empty.yaml(2 hunks)schema/tests/data/project/negative/documentation_invalid.yaml(2 hunks)schema/tests/data/project/negative/documentation_non_unique.yaml(1 hunks)schema/tests/data/project/negative/documentation_null.yaml(1 hunks)schema/tests/data/project/negative/downloads_empty.yaml(1 hunks)schema/tests/data/project/negative/downloads_invalid.yaml(1 hunks)schema/tests/data/project/negative/downloads_non_unique.yaml(1 hunks)schema/tests/data/project/negative/downloads_null.yaml(1 hunks)schema/tests/data/project/negative/events_empty.yaml(1 hunks)schema/tests/data/project/negative/events_invalid.yaml(0 hunks)schema/tests/data/project/negative/events_non_unique.yaml(1 hunks)schema/tests/data/project/negative/events_null.yaml(1 hunks)schema/tests/data/project/negative/leaders_empty.yaml(1 hunks)schema/tests/data/project/negative/leaders_non_unique.yaml(1 hunks)schema/tests/data/project/negative/leaders_null.yaml(1 hunks)schema/tests/data/project/negative/leaders_undefined.yaml(1 hunks)schema/tests/data/project/negative/level_invalid.yaml(1 hunks)schema/tests/data/project/negative/level_undefined.yaml(1 hunks)schema/tests/data/project/negative/license_invalid.yaml(1 hunks)schema/tests/data/project/negative/logo_empty.yaml(1 hunks)schema/tests/data/project/negative/logo_non_unique.yaml(1 hunks)schema/tests/data/project/negative/logo_null.yaml(1 hunks)schema/tests/data/project/negative/mailing_list_empty.yaml(1 hunks)schema/tests/data/project/negative/mailing_list_invalid.yaml(1 hunks)schema/tests/data/project/negative/mailing_list_null.yaml(1 hunks)schema/tests/data/project/negative/name_empty.yaml(1 hunks)schema/tests/data/project/negative/name_null.yaml(1 hunks)schema/tests/data/project/negative/name_undefined.yaml(1 hunks)schema/tests/data/project/negative/pitch_empty.yaml(1 hunks)schema/tests/data/project/negative/pitch_null.yaml(1 hunks)schema/tests/data/project/negative/pitch_undefined.yaml(1 hunks)schema/tests/data/project/negative/repositories_empty.yaml(1 hunks)schema/tests/data/project/negative/repositories_non_unique.yaml(1 hunks)schema/tests/data/project/negative/repositories_null.yaml(1 hunks)schema/tests/data/project/negative/social_media_empty.yaml(1 hunks)schema/tests/data/project/negative/social_media_non_unique.yaml(1 hunks)schema/tests/data/project/negative/social_media_null.yaml(1 hunks)schema/tests/data/project/negative/sponsors_empty.yaml(1 hunks)schema/tests/data/project/negative/sponsors_non_unique.yaml(1 hunks)schema/tests/data/project/negative/sponsors_null.yaml(1 hunks)schema/tests/data/project/negative/tags_empty.yaml(1 hunks)schema/tests/data/project/negative/tags_non_unique.yaml(1 hunks)schema/tests/data/project/negative/tags_null.yaml(1 hunks)schema/tests/data/project/negative/tags_undefined.yaml(1 hunks)schema/tests/data/project/negative/type_empty.yaml(1 hunks)schema/tests/data/project/negative/type_null.yaml(1 hunks)schema/tests/data/project/negative/type_undefined.yaml(1 hunks)schema/tests/data/project/negative/website_empty.yaml(1 hunks)schema/tests/data/project/negative/website_null.yaml(1 hunks)schema/tests/data/project/positive/optional_properties.yaml(3 hunks)schema/tests/data/project/positive/required_properties.yaml(1 hunks)schema/tests/project_test.py(3 hunks)
💤 Files with no reviewable changes (2)
- schema/tests/data/project/negative/events_invalid.yaml
- schema/tests/data/committee/negative/events_invalid.yaml
✅ Files skipped from review due to trivial changes (37)
- schema/tests/data/common/website/negative/url_invalid.yaml
- schema/tests/data/common/tag/positive/required_properties.yaml
- schema/tests/data/common/tag/negative/tag_undefined.yaml
- schema/tests/data/common/name/positive/required_properties.yaml.yaml
- schema/tests/data/common/event/negative/url_null.yaml
- schema/tests/data/common/mailing_list/positive/required_properties.yaml
- schema/tests/data/common/tag/negative/tag_empty.yaml
- schema/tests/data/common/tag/positive/optional_properties.yaml
- schema/tests/data/common/website/negative/url_null.yaml
- schema/tests/data/common/name/negative/name_null.yaml
- schema/tests/data/common/mailing_list/negative/email_null.yaml
- schema/tests/data/common/tag/negative/tag_null.yaml
- schema/tests/data/common/event/negative/title_null.yaml
- schema/tests/data/common/event/negative/url_undefined.yaml
- schema/tests/data/common/event/negative/description_empty.yaml
- schema/tests/data/common/name/negative/description_null.yaml
- schema/tests/data/common/website/negative/description_empty.yaml
- schema/tests/data/common/tag/negative/description_null.yaml
- schema/tests/data/common/mailing_list/positive/oprional_properties.yaml
- schema/tests/data/common/mailing_list/negative/description_empty.yaml
- schema/tests/data/common/tag/negative/description_empty.yaml
- schema/tests/data/common/event/positive/optional_properties.yaml
- schema/tests/data/common/website/positive/optional_properties.yaml
- schema/tests/data/common/event/negative/title_undefined.yaml
- schema/tests/data/common/mailing_list/negative/description_null.yaml
- schema/tests/data/common/event/negative/description_null.yaml
- schema/tests/data/common/name/negative/description_empty.yaml
- schema/tests/data/common/mailing_list/negative/email_empty.yaml
- schema/tests/data/common/website/negative/description_null.yaml
- schema/tests/data/common/event/positive/required_properties.yaml
- schema/tests/data/common/website/negative/url_empty.yaml
- schema/tests/data/common/event/negative/url_invalid.yaml
- schema/tests/data/common/event/negative/url_empty.yaml
- schema/tests/data/common/name/positive/optional_properties.yaml
- schema/tests/data/common/website/negative/url_undefined.yaml
- schema/tests/data/common/name/negative/name_empty.yaml
- schema/tests/data/common/website/positive/required_properties.yaml
🔇 Additional comments (359)
schema/tests/data/committee/negative/name_undefined.yaml (1)
11-13: Structured Tags Representation:
The tags field now correctly represents each tag as an object with avaluekey, which improves consistency and allows for potential future expansion (e.g., additional attributes for each tag).schema/common.json (11)
14-21: Community Platform Enumeration Update:
Theplatformproperty in thecommunitydefinition now explicitly restricts values to"discord"and"slack". This enhances data integrity; please ensure these limits align with your overall requirements.
28-31: Community Required Fields Consistency:
The modifiedrequiredarray for thecommunityobject (ensuring"platform"and"url"are mandatory) is consistent with the new restrictions.
35-60: New Event Definition Added:
The addition of theeventobject definition, with its own properties and required"url", standardizes the representation of events. The inclusion of descriptive keys and minimal length validations (for thedescriptionandtitle) is a plus.
81-85: Logo Required Properties:
The update in thelogodefinition now requires"small","medium", and"large"properties. This ensures that all logo sizes are consistently provided.
89-110: Mailing List Definition:
The newmailing_listdefinition is well-structured. Enforcing an email format and a minimum length adds robustness to the schema.
158-161: Person Definition Requirement Update:
Thepersondefinition now requires only the"github"property. Please verify that this change is intentional and that no additional fields (e.g., email or name) should be mandatory based on your project’s needs.
220-225: Social Media Platform Enumeration:
Theplatformproperty forsocial_medianow accepts only"bluesky","linkedin","x", and"youtube". Ensure that this list is comprehensive for all expected social platforms.
234-237: Social Media Required Fields:
The updatedrequiredlist forsocial_media(enforcing"platform"and"url") is clear and consistent with the definition.
266-269: Sponsor Required Fields Update:
Requiring only"name"and"url"in thesponsorobject seems to be a thoughtful simplification. Make sure that optional properties (likedescriptionandlogo) are handled appropriately in validations downstream.
273-293: Tag Definition Enhancement:
The newtagobject, which requires a"value"and optionally includes a descriptive field, offers a more structured approach compared to a simple string. This looks well implemented.
294-315: Website Definition:
Thewebsiteobject is clearly defined, with a required"url"property and proper validations (e.g., URI format and minimal length).schema/tests/data/common/event/negative/title_empty.yaml (1)
1-3: Event Title Negative Test Case:
This test case intentionally provides an empty string for thetitlefield. Given the schema requires a minimum length (of 10 characters) for the event title, this negative test will help validate the enforcement of that constraint.schema/tests/data/chapter/negative/tags_null.yaml (2)
8-9: Structured Name Field Conversion:
Converting thenamefield from a plain string to a list of objects with avaluekey is executed correctly, aligning with the new common schema definitions.
10-11: Empty Tags Field Validation:
The presence of thetagskey without any entries appears intentional for this negative test case to verify the schema’s handling of missing or null tag data.schema/tests/data/committee/negative/tags_null.yaml (2)
9-10: Structured Name Field for Committee:
The update transforms thenamefield into a list containing an object with thevaluekey, ensuring consistency with other schema changes.
12-13: Empty Tags Field in Committee Schema:
Similarly, thetagsfield here is intentionally left empty, serving as a negative test to validate behavior when tag information is missing.schema/tests/data/chapter/negative/tags_undefined.yaml (1)
8-9: Standardize thenamefield structure.
Updating thenamefield to an array of objects with thevaluekey aligns with the new common schema. Please ensure all schema validators and consumers are updated to expect this structured format.schema/tests/data/chapter/negative/tags_empty.yaml (1)
8-9: Convertnameto structured format.
The change converts thenamefield from a plain string to a list containing an object with avaluekey. This is consistent with the project’s move to a structured schema, improving maintainability and extensibility.schema/tests/data/project/negative/tags_null.yaml (1)
9-10: Restructure thenamefield for consistency.
Changing thenamefield to use an array with- value: ...provides consistency with other schema definitions. Please check that schema consumers can correctly interpret this new structure.schema/tests/data/project/negative/name_null.yaml (1)
11-13: Refine thetagsfield structure.
Encapsulating each tag within a dictionary using thevaluekey improves the data structure and future extensibility. Ensure that any code processing these tags is updated accordingly.schema/tests/data/project/negative/tags_undefined.yaml (1)
9-10: Harmonize thenamefield structure.
This update transitions thenamefield from a simple string to a structured array format (- value: ...), which is in line with the project's schema standardization. Double-check that all related validations accommodate this change.schema/tests/data/chapter/negative/name_undefined.yaml (1)
9-11: Updated tags structure aligns with the schema standardization efforts.The change from simple string tags to objects with a
valueproperty is consistent with the PR's objective of extracting common properties across schemas. This structured approach enhances extensibility, allowing for potential additional tag properties in the future while maintaining backward compatibility.schema/tests/data/committee/negative/tags_empty.yaml (1)
9-10: Name field follows the new standardized structure.The name field now follows the same pattern as tags, using an array of objects with a
valueproperty instead of a simple string. This is consistent with the schema standardization effort across different entity types (chapters, committees, projects) and allows for future extensibility.schema/tests/data/project/negative/tags_empty.yaml (1)
9-10: Name field adopts the standardized structure format.The name field update from a simple string to a list containing an object with a
valueproperty maintains consistency with other entity schemas. This standardization simplifies validation logic and schema maintenance while preserving semantic meaning.schema/tests/common/tags_test.py (1)
1-28: Well-structured test suite for the common tag schema.This new test file provides comprehensive coverage for the tag schema validation, with both positive and negative test cases. The parameterized approach efficiently tests various invalid scenarios with specific error messages, ensuring the schema behaves as expected.
The error messages in the test cases clearly indicate the validation requirements:
- Tags and descriptions must not be empty strings
- Tags and descriptions must be strings (not null)
- Tags must have a "value" property
This aligns perfectly with the PR's objective of extracting common properties and standardizing schemas.
schema/tests/data/committee/negative/tags_undefined.yaml (1)
9-10: Schema structure change aligns with common properties extraction.The change from a simple string value to an array containing an object with a "value" key aligns with the PR objective of extracting common properties into shared schema definitions. This new structure provides better flexibility and extensibility for future enhancements.
schema/tests/data/project/negative/name_undefined.yaml (1)
10-13: Consistent schema restructuring for tags property.The tags property structure has been updated from a list of simple strings to a list of objects with a "value" key. This change is consistent with the overall schema restructuring approach and allows for future extensibility (e.g., adding additional metadata to tags).
schema/tests/common/events_test.py (4)
1-6: Well-structured module with appropriate imports.The module has a clear docstring and imports the necessary dependencies.
7-8: Good use of constant for schema name.Using a constant for the schema name makes the code more maintainable and reduces the risk of typos.
10-26: Comprehensive negative test cases for event schema validation.The parameterized test covers a wide range of validation scenarios including empty values, null values, and invalid URLs. The error messages are specific and will help with debugging failed tests.
28-31: Simple and effective positive test case.The positive test case leverages a common test utility, which promotes code reuse and consistency across test files.
schema/tests/data/chapter/negative/name_null.yaml (2)
7-8: Correctly demonstrates a null name for negative testing.This negative test case correctly shows a scenario where the name field exists but has no value, which should trigger validation errors based on the schema requirements.
9-11: Consistent restructuring of tags property.The tags property has been updated to match the new schema structure, using objects with a "value" key instead of simple strings. This is consistent with the changes seen in other files and supports the PR's goal of extracting common properties.
schema/tests/common/name_test.py (3)
1-7: Good module documentation and constant definition.The module has appropriate documentation and clearly defines the schema name constant. The imports are properly organized.
10-21: Well-structured parameterized tests for negative cases.The use of pytest's parametrization is a good approach for testing multiple negative test cases. The error messages are specific and correctly associated with their respective test files.
24-27: Good implementation of positive test cases.The positive test function is concise and properly documented. It leverages the common test utilities, which promotes code reuse.
schema/tests/common/website_test.py (3)
3-7: Appropriate imports and constant definition.The imports are properly organized, and the schema name constant is clearly defined.
10-24: Comprehensive parameterized tests for negative cases.The test cases cover a good range of validation scenarios including empty descriptions, null values, and various URL validation cases. The parametrization approach is efficient.
26-29: Appropriate positive test function.The positive test function follows the same pattern as other schema tests, maintaining consistency across the codebase.
schema/tests/data/chapter/negative/leaders_null.yaml (2)
3-4: Updated schema structure for name property.The name property has been transformed from a simple string to a structured object within an array. This change aligns with the PR objective of extracting common properties across schemas.
5-8: Consistent structure for tags property.The tags have been updated to use the same object-based structure as other properties, maintaining consistency with the schema changes.
schema/tests/data/chapter/negative/events_non_unique.yaml (3)
2-4: Structured format for events with duplicate URLs.The events property now uses a structured format with the 'url' key, which is consistent with the common schema extraction. The test case correctly includes duplicate URLs for testing non-uniqueness validation.
11-12: Standardized name property format.The name property has been updated to use the new array-of-objects format, maintaining consistency with other schema changes.
13-16: Consistent tags property structure.The tags structure has been standardized to use the value-based object format, aligning with the common schema approach.
schema/tests/data/project/negative/pitch_empty.yaml (2)
9-10: Structured 'name' Field Update
Thenamefield now uses a list containing a dictionary with avaluekey. This change is consistent with the extraction of common properties and improves extensibility. Please ensure that any consumers of this field are updated to expect an array.
13-15: Structured 'tags' Field Update
Thetagsfield has been updated from a list of simple strings to a list of objects containing avaluekey. This enhances consistency across schema definitions. Confirm that downstream validations and tests correctly handle the new structure.schema/tests/data/project/negative/downloads_non_unique.yaml (2)
5-6: Updated 'name' Field for Consistency
Thenameproperty is now structured as an array with an object containing thevaluekey. This change aligns with the goals of extracting common properties and standardizing schema definitions.
13-15: Enhanced 'tags' Field Structure
The transformation of thetagsfield into a list of dictionaries improves uniformity across schema files. Given that this is a negative test case, ensure that duplicate tag handling (if enforced by schema constraints) is properly validated.schema/tests/data/project/negative/leaders_undefined.yaml (2)
3-4: Refined 'name' Field Format
Thenamefield now adheres to the structured format with avaluekey inside an array, in line with the common properties extraction. This improves data consistency across modules.
7-9: Standardized 'tags' Field Representation
Updating thetagsfield to use objects with avaluekey enhances clarity and future extensibility. Ensure that all related test validations are updated to reflect this new structure.schema/tests/data/project/negative/tags_non_unique.yaml (2)
9-10: Consistent 'name' Field Update
Thenameproperty now uses the structured array format, which is in line with the new common property extraction. This change appears correct and consistent with other schema updates.
13-14: Intentional Duplicate in 'tags' for Negative Testing
Thetagsfield now contains duplicate entries (both withvalue: example-tag-1), likely to test uniqueness constraints. Please verify that the negative test properly captures and reports the non-uniqueness error as expected.schema/tests/data/project/negative/downloads_invalid.yaml (2)
4-5: Updated 'name' Field Conformance
The transition of thenamefield to the structured list format (with avaluekey) aligns well with the pull request objectives. Ensure that any schema validations expecting a simple string are updated accordingly.
11-14: Revised 'tags' Field Structure
Thetagsfield has been standardized to a list of objects containing avaluekey. This change is consistent across the schema files. Verify that this negative test still triggers the expected failures (if any) related to invalid downloads while processing the new tags structure.schema/tests/data/committee/negative/logo_empty.yaml (2)
10-11: Refactor "name" Field Structure
The "name" field is now represented as an array containing an object with a "value" key. This change improves consistency with the new common schema properties.
14-16: Update "tags" Field Structure
The "tags" field has been transformed from a list of plain strings into an array of objects (each with a "value" key). This aligns with the standardized structure across schemas. Please verify that the new tag values meet the intended requirements.schema/tests/data/chapter/negative/logo_null.yaml (2)
9-10: Restructure "logo.name" Field
"logo.name" is now refactored to be an array with an object that contains the "value" key. This change increases the expressiveness and future extensibility of the schema.
12-14: Standardize "tags" Field
The tags are now provided as objects with a "value" key rather than simple strings. This enhancement supports consistency across different schema files.schema/tests/data/committee/negative/logo_non_unique.yaml (2)
16-17: Refactor "logo.name" Structure
The "name" field under "logo" is converted to an array with an object (key "value"). This modification follows the new common properties approach and should harmonize with updates in related schemas.
20-22: Update "tags" Field Structure
By transitioning the "tags" field to a list of objects with a "value" key, the file now conforms with the newly established schema pattern. Please ensure that any validations on tag uniqueness are also applied as needed.schema/tests/data/project/negative/leaders_non_unique.yaml (2)
6-7: Convert "name" to an Object Array
The "name" field is updated from a simple string to an array containing an object with a "value" key. This is consistent with the extraction of common properties and should simplify future modifications.
10-12: Refactor "tags" Field Format
The "tags" field now contains objects structured as { value: ... } instead of plain strings. Confirm that any logic consuming these tags is updated accordingly and that these tag representations meet the new requirements.schema/tests/data/project/negative/mailing_list_null.yaml (2)
9-10: Restructure "mailing_list.name" Field
The "mailing_list" section now features "name" as an array with an object holding a "value" key rather than a simple key-value pair. This enhances consistency across schemas and allows for additional metadata in the future.
13-15: Standardize "tags" Field
The transformation of the "tags" field into a list of objects with a "value" key brings it in line with the common schema properties. Ensure that downstream validations (if any) are adjusted to accommodate the new structure.schema/tests/data/chapter/positive/optional_properties.yaml (4)
11-12: Ensure Consistent Event Structure
Changing the events entries to a list of objects with aurlkey standardizes the design and aligns with the shared schema definitions. Please verify that related validations and documentation reflect this update.
24-25: Standardize Chapter Name Format
Converting the chapternamefrom a plain string to a list containing an object with avaluekey enhances consistency across schema files.
37-39: Refactor Tags to Object Format
Updating thetagsproperty to use objects with avaluekey improves data uniformity. Ensure that any consumers of these tags are adjusted for the new structure.
40-42: Enhance Website Property Structure
The change to representwebsiteas a list of objects (each including adescriptionandurl) further enforces a consistent and extensible schema design.schema/tests/data/project/negative/documentation_empty.yaml (2)
3-4: Standardize Project Name Structure
Restructuring thenameproperty into a list containing an object with avaluekey aligns the data with the new schema standards. Please ensure that any components processing this field are updated accordingly.
14-16: Standardize Documentation Tags Format
Converting thetagsfield to a list of objects with avaluekey improves consistency with other schema changes. Verify that any logic which interprets these tags is also updated.schema/tests/data/project/negative/downloads_null.yaml (2)
3-4: Update Downloads Name Field
Transforming thenameunderdownloadsinto a list with avaluekey supports the overall refactor of schema properties. This change should help maintain uniformity across the project.
11-13: Refactor Downloads Tags Field
Refactoringtagsto be a list of objects with avaluekey is a good move for consistency. Ensure that the corresponding schema validations and any parsing logic are updated.schema/tests/data/chapter/negative/community_null.yaml (2)
9-10: Restructure Chapter Name for Consistency
Updating thenamefield to a list containing an object with avaluekey brings it in line with the refactored schema design.
12-14: Standardize Community Tags Field
Changing thetagsentries into objects with avalueattribute improves consistency and clarity. Please double-check that schema validations and user interfaces processing these tags accommodate the nested structure.schema/tests/data/project/negative/events_non_unique.yaml (3)
3-4: Validate Duplicate Events for Uniqueness Constraint
The events list now includes duplicate entries (both pointing tohttps://example.com/event1). Since this is a negative test case, it appears intended to verify that the schema enforces uniqueness. Consider adding an inline comment to clarify that the duplicate is deliberate for testing purposes.
12-13: Consolidate Project Name Format
Restructuring thenamefield into a list with an object containing avaluekey aligns with the new schema guidelines.
16-18: Standardize Tags Structure
Transformingtagsinto a list of objects with avaluekey is consistent with the overall schema refactoring. Verify that any error messages or validations reflect this nested structure.schema/tests/data/project/negative/website_empty.yaml (3)
8-9: Consistent 'name' Field Structure.
Thenamefield is now represented as a list with an object containing avaluekey. This change aligns perfectly with the new common properties extraction and ensures that all schema references have uniform formatting.
12-14: Restructured 'tags' Field.
Thetagsfield has been updated so that each tag is encapsulated in an object with avaluekey. This improves consistency across schema files and facilitates future extensions.
16-16: Standardized 'website' Representation.
Changing thewebsitefield from an empty string to an empty list enforces a uniform structure as expected by the new schema designs. Ensure that any schema validation or downstream processing is updated to handle a list forwebsite.schema/tests/data/chapter/negative/logo_empty.yaml (2)
9-10: Updated 'name' Property Format.
Thenamefield has been refactored to a list containing an object with avaluekey, which is consistent with the extraction of common properties in the schemas.
12-14: Refined 'tags' Field Representation.
The transformation of thetagsfield into a list of objects with avaluekey ensures uniformity with other schema definitions.schema/tests/data/project/negative/logo_non_unique.yaml (2)
16-17: Standardizing 'name' Field.
The new structure for thenamefield—a list containing an object with avaluekey—matches the intended format from the common properties extraction. Verify that downstream validations consider this standardized structure.
20-22: Consistent 'tags' Field Format.
The update to thetagsfield—transforming it into a list of objects with avaluekey—ensures that tag representations are consistent across schema files. This is especially important in negative tests that validate schema uniqueness and correctness.schema/tests/data/committee/negative/scope_invalid.yaml (2)
9-10: Reformatted 'name' Field.
Changing thenamefield to follow the list-of-objects format with avaluekey is in line with our new common properties strategy. Double-check that any validations regarding committee scope still operate as expected given the structural changes.
11-14: Updated 'tags' Schema.
The conversion of thetagsfield to a structured format (list of objects with avaluekey) reinforces consistency across our schema definitions. Ensure that error detection for invalid schemas takes these changes into account.schema/tests/data/project/negative/name_empty.yaml (2)
8-9: Enforced Structured 'name' Field Even When Empty.
Even though the negative test presents an emptynamevalue, the structure now conforms to the common format (a list with an object containing avaluekey). Make sure the schema validation catches empty or missingnamevalues appropriately.
12-14: Uniform 'tags' Field Structure.
The modifications to thetagsfield—encapsulating each tag in an object with avaluekey—ensure consistency across all schema files. This uniformity is beneficial for both maintenance and future extensibility.schema/tests/data/committee/negative/members_null.yaml (2)
3-4: Structured "name" Field Conversion
The conversion of thenamefield from a simple string into a list containing an object with avaluekey aligns with the new common schema approach. This enhancement improves extensibility and consistency across schema files.
7-9: Structured "tags" Field Update
The transformation of thetagsfield into a list of objects (each with avaluekey) is consistent with the updated schema design. This structured representation will facilitate better validations and potential future extensions.schema/tests/data/chapter/negative/tags_non_unique.yaml (2)
8-9: Consistent "name" Field Restructuring
The update of thenamefield to use a list of objects (with thevaluekey) is applied correctly. This change is consistent with the extraction of common properties.
11-12: Validation of Duplicate "tags" Entries
Thetagsfield now uses structured objects; however, duplicate values (example-tag-1appearing twice) are present. Since this file is intended as a negative test case, please ensure that the schema correctly enforces uniqueness for tag entries and that proper validation errors are produced.schema/tests/data/project/negative/logo_null.yaml (2)
10-11: Structured "logo.name" Field Update
Thelogo.namefield has been updated to a structured format (a list with an object containing avaluekey) as required by the common schema. This change promotes consistency across project-related files.
14-16: Restructured "tags" Field for Project
The tags for the project are now represented as objects withvaluekeys. This structured approach aligns with the overall schema update and should improve downstream validations.schema/tests/data/project/negative/documentation_invalid.yaml (2)
4-5: Updated "name" Field Structure in Documentation
The change converting thenamefield to a list of objects (with avaluekey) reflects the new schema standard. Ensure that any associated validation error messaging focuses on the intended documentation issues rather than the restructuring itself.
15-17: Structured "tags" Field in Documentation
Thetagsfield has been successfully updated to a structured format. As this file is for testing invalid documentation scenarios, please verify that the errors produced by the schema validator are specific to the documentation's requirements—and not merely due to the new structure.schema/tests/data/chapter/negative/social_media_non_unique.yaml (2)
8-9: Converting "name" Field to Structured Format
Thenamefield for the chapter has been updated correctly to use a list of objects with avaluekey. This promotes consistency with the extracted common properties across schemas.
16-18: Structured "tags" Field with Uniqueness Consideration
Thetagsfield is now represented as a list of objects, which is consistent with the revised schema. Given the file’s intent to test non-unique social media values, please verify that the schema validation properly flags duplicate entries (if applicable) and that error messages accurately reflect the uniqueness constraint enforcement.schema/tests/data/chapter/negative/community_empty.yaml (2)
9-10: Structured "name" field update:
The conversion of thenamefield from a simple scalar to a list of objects (with the keyvalue) is correctly applied. This change aligns well with the new common properties design.
12-14: Structured "tags" field update:
The update converting each tag into a structured object is consistent with the schema-wide refactoring. Just ensure that any consumers of this schema update their parsing logic accordingly.
[approved, verify]schema/tests/data/chapter/negative/blog_invalid.yaml (2)
8-9: Structured "name" field update:
The change from a simple string to a list containing an object with thevaluekey improves consistency with the new schema standards.
11-13: Structured "tags" field update:
The transformation of tag items to a structured format is well implemented. Please verify that any downstream validations or processing logic have been adjusted to accept this new format.
[approved, verify]schema/tests/data/committee/negative/social_media_empty.yaml (2)
9-10: Structured "name" field update for committee:
Updating thenamefield to a list with an object containingvalueenhances uniformity. This change is in line with similar updates in other schema files.
14-16: Structured "tags" field update for committee:
The conversion of thetagsfield entries to objects with avalueproperty is consistent with the overall schema refactoring. Ensure that any related test validations are updated accordingly.
[approved, verify]schema/tests/data/committee/negative/meeting_minutes_null.yaml (2)
9-11: Review "meeting_minutes" structured update:
The intention to convert themeeting_minutesfield from a simple string (or null) to a structured format is clear. However, note that the update introduces a nestedname:key undermeeting_minutesinstead of directly using a uniform key (likevalue). Please confirm that this nested structure is deliberate and that downstream consumers are adjusted to this slight deviation from the pattern used in other fields.
[verify, offer_assistance]
13-16: Structured "tags" field update:
The modifications converting tag entries to use a structured object with avaluekey are correctly implemented.
[approved, verify]schema/tests/data/chapter/negative/blog_empty.yaml (2)
8-9: Structured "name" field update:
The update to transform thenamefield into a list containing an object withvalueis consistent with the overall schema improvements.
11-13: Structured "tags" field update:
Converting each tag to a structured object enhances clarity and uniformity in the schema. Please ensure that validations expecting string-based tags are updated accordingly.
[approved, verify]schema/tests/data/project/negative/leaders_null.yaml (3)
4-5: Schema structure updated fornameproperty.The
nameproperty has been modified to use the new structured format with a list containing objects with avaluekey, aligning with the extraction of common properties across schemas.
7-10: Schema structure updated fortagsproperty.The
tagsproperty has been restructured from a list of simple strings to a list of objects with avaluekey, consistent with the schema standardization across the project.
1-12:✅ Verification successful
Verify consistency with schema definition.
This test file has been updated to match the new schema structure, but ensure that the test case still properly tests the "leaders_null" scenario as indicated by the filename.
🏁 Script executed:
#!/bin/bash # Description: Verify that this test file correctly tests for null leaders # and that it matches the actual schema definition. # First, check the schema definition for projects cat schema/project.json | jq '.properties.leaders' # Then check if this test passes validation with the schema echo "Checking if this file is properly testing null leaders scenario..." fd -t f -e py "project_test.py" | xargs grep -A 20 "leaders_null"Length of output: 2200
Ensure "leaders_null.yaml" accurately triggers schema validation errors.
- The schema now requires
leadersto be an array with at least 2 items. The YAML file under test provides an empty key (leaders:) which correctly evaluates tonullin YAML.- The test expectation in
project_test.pyconfirms that anullvalue forleaderstriggers the error: "None is not of type 'array'".- The code snippet reflects the intended test case, and the output from the validation script further verifies its consistency with the updated schema definition.
schema/tests/data/project/positive/optional_properties.yaml (5)
19-20: Schema structure updated foreventsproperty.The
eventsproperty has been modified to use a structured format with aurlkey, consistent with the extraction of common properties across schemas.
33-34: Schema structure updated fornameproperty.The
nameproperty has been updated to follow the new structured format with a list containing objects with avaluekey, aligning with the schema standardization.
58-61: Schema structure updated fortagsproperty.The
tagsproperty has been restructured from a list of simple strings to a list of objects with avaluekey, consistent with the schema standardization.
63-64: Schema structure updated forwebsiteproperty.The
websiteproperty has been modified to use a structured format with aurlkey, consistent with the extraction of common properties.
1-65:✅ Verification successful
Verify schema validation.
The file has been updated to match the new schema structure. Let's verify that it passes validation against the updated schema definition.
🏁 Script executed:
#!/bin/bash # Description: Verify that this test file passes validation with the updated schema # Check the test file for this positive test case fd -t f -e py "project_test.py" | xargs grep -A 10 "optional_properties" # Check if validation is performed correctly for the updated schema python -c "import json; schema = json.load(open('schema/project.json')); print('Schema properties:', list(schema['properties'].keys()))"Length of output: 471
Schema validation passed successfully.
The optional properties test file (schema/tests/data/project/positive/optional_properties.yaml) conforms to the updated schema structure. The executed script confirms that all expected keys (including collections like community, documentation, repositories, etc.) are correctly defined inschema/project.json. No further action is required.schema/tests/common/mailing_list_test.py (3)
1-6: Well-structured test module setup.Good job on creating a well-structured test module with a clear docstring and proper imports. The test leverages common test functions which promotes code reusability.
9-22: Comprehensive negative test cases for mailing list schema.The parameterized test cases cover important validation scenarios including empty and null values for required fields. This is a good practice for ensuring schema robustness.
24-26: Positive test case implementation.The positive test case implementation is concise and reuses the common test function, promoting code reuse and consistency across test files.
schema/tests/data/project/negative/audience_null.yaml (3)
8-9: Schema structure updated fornameproperty.The
nameproperty has been modified to use the new structured format with a list containing objects with avaluekey, consistent with the extraction of common properties.
11-14: Schema structure updated fortagsproperty.The
tagsproperty has been restructured from a list of simple strings to a list of objects with avaluekey, aligning with the schema standardization across the project.
1-16:✅ Verification successful
Verify test reflects its purpose.
This file is named
audience_null.yamlbut theaudienceproperty is present (although empty). Let's verify that this test case properly validates the scenario it's intended to test.
🏁 Script executed:
#!/bin/bash # Description: Verify that audience_null.yaml correctly tests for null audience # Check the schema definition for audience property cat schema/project.json | jq '.properties.audience' # Check if this test is referenced in project tests fd -t f -e py "project_test.py" | xargs grep -A 10 "audience_null" # Compare with other null test cases echo "Comparing with other null test cases..." fd -p "schema/tests/data/project/negative" -name "*null.yaml" | grep -v "audience_null.yaml" | head -n 3 | xargs catLength of output: 1804
Verification: Test correctly validates the null audience scenario.
Theaudience_null.yamlfile intentionally provides anaudience:key with no value (yielding a null value per YAML specification), which triggers the appropriate validation error—"None is not one of ['breaker', 'builder', 'defender']"—as confirmed inschema/project.jsonand referenced inproject_test.py. Therefore, the test accurately reflects its purpose, and no changes are needed.schema/tests/chapter_test.py (3)
32-34: The error message now correctly reflects the updated data structure of events.The error message has been updated to match the new data structure where events are now represented as an array of objects with a
urlproperty, rather than simple strings. This change is consistent with the schema modifications.
56-57: Updated error messages match the new data structure for name field.The error messages for
name_empty.yamlandname_null.yamlhave been correctly updated to reflect that the name field is now an array (containing objects with avalueproperty) instead of a simple string. This ensures test accuracy with the new schema structure.
83-84: Updated error messages for website field align with new structure.The error messages for
website_empty.yamlandwebsite_null.yamlhave been correctly updated to reflect that the website field is now an array rather than a simple string/URI. This maintains consistency with the schema changes.schema/tests/data/chapter/negative/logo_non_unique.yaml (2)
15-16: Name field structure updated to array of objects with value property.The name field has been changed from a simple string to an array containing an object with a
valueproperty, which aligns with the schema changes made across the project.
17-20: Tags field updated to use object structure with value property.The tags have been transformed from an array of simple strings to an array of objects, each with a
valueproperty. This change is consistent with the schema modifications throughout the project.schema/tests/data/project/negative/audience_invalid.yaml (2)
8-9: Name field updated to use array of objects structure.The name field has been modified from a simple string to an array containing an object with a
valueproperty, consistent with the schema changes across the project.
11-14: Tags field structure updated to use objects with value property.The tags field has been changed from an array of strings to an array of objects with a
valueproperty. This change is consistent with the schema modifications throughout the project.schema/tests/data/project/negative/documentation_null.yaml (3)
9-10: Name field updated to use array of objects structure.The name field has been modified from a simple string to an array containing an object with a
valueproperty, in line with schema changes across the project.
12-15: Tags field structure updated to use objects with value property.The tags field has been changed from an array of strings to an array of objects with a
valueproperty. This change is consistent with the schema modifications throughout the project.
1-17:❓ Verification inconclusive
Verify the impact on existing data and consuming code.
The changes to the data structure (particularly for
nameandtags) are significant and likely impact existing code that consumes this schema. Ensure that all code reading from or writing to these schemas has been updated to handle the new structure.
🏁 Script executed:
#!/bin/bash # Search for code that might be accessing these fields directly echo "Looking for code that accesses name and tags fields directly..." rg -t py -t js -t ts "\.name\b|\.tags\b|\[\"name\"\]|\[\"tags\"\]|\['name'\]|\['tags'\]" --no-headingLength of output: 63003
Action Required: Verify and Update Code Handling for New
nameandtagsStructureThe updated schema now represents the
nameandtagsfields as structured (likely array-based) values rather than simple strings. A grep search across the project shows numerous components—ranging from backend models and admin utilities to tests and frontend components—accessing these fields directly. This widespread usage indicates that consuming code might be expecting a primitive value, which could lead to type errors or unexpected behavior.Key areas to review:
- Backend Models & Logic: Files like
backend/apps/owasp/models/common.py,committee.py,chapter.py, and various tests still referenceobj.nameand directly parsetags.- Test Suites: Several tests (e.g., in
backend/tests/github/models/...andbackend/tests/owasp/models/...) assert string equality onnameandtags.- Frontend Components: Multiple UI components (in React/TypeScript files) rely on the direct use of
.name.Please confirm that all parts of the code reading from or writing to these schemas have been updated to handle the new data structure. Depending on the intended design, you may need to adjust your access patterns (for example, extracting the value from array elements) and update tests to reflect these changes.
schema/tests/data/project/negative/sponsors_non_unique.yaml (2)
9-10: Structured “name” field update
The “name” field has been updated from a simple scalar value to a list containing a dictionary with the key “value”. This change aligns with the new common schema extraction, improving consistency and extensibility.
18-20: Structured “tags” field update
Similarly, the “tags” field now consists of a list of dictionaries instead of plain string entries. This consistent transformation helps in managing schema properties centrally and allows for potential future extensions.schema/tests/data/project/negative/demo_invalid.yaml (2)
10-11: Revised “name” field to structured format
The “name” field change—from a plain string to an array of objects with the key “value”—ensures better consistency with the overall schema design. Verify that all validations and error messages reflect this new format.
14-16: Revised “tags” field to structured format
The transformation of “tags” into a list of dictionaries with “value” keys provides a uniform structure across schema files. This update should simplify schema maintenance and implementation of future enhancements.schema/tests/data/project/negative/events_empty.yaml (2)
9-10: Updated “name” field structure
Changing the “name” field to an array of dictionaries (with “value” keys) aligns this schema with the standardized format across the project. Ensure that empty-event cases are correctly handled in downstream processing.
13-15: Updated “tags” field structure
The updated “tags” field now follows the new structured format. This ensures improved consistency and allows for possible future extensions (such as additional metadata per tag) without significant refactoring.schema/tests/data/project/negative/repositories_empty.yaml (2)
9-10: Standardized “name” field change
The “name” field here has been standardized to an array format with a “value” key, matching changes made in other project schema files. This will help maintain consistency across varied schema definitions.
14-16: Standardized “tags” field change
Updating “tags” to a structured format (list of dictionaries with “value”) ensures that all related schema definitions have a uniform representation. Confirm that the modifications work correctly in all relevant test cases.schema/tests/data/chapter/negative/leaders_empty.yaml (2)
3-4: Consistent “name” field transformation
The “name” field for the chapter schema has been updated to use a list of objects with a “value” key. This change is consistent with the common extraction logic implemented across project schemas.
6-8: Consistent “tags” field transformation
Transforming the “tags” field into a list of dictionaries ensures that chapter schemas are aligned with project schemas. This uniformity supports maintainability and potential schema extension in the future.schema/tests/data/project/negative/blog_empty.yaml (2)
10-11: Standardized Name Field Structure.
Thenamefield is now defined as a list containing an object with avaluekey instead of a plain string. This change enhances extensibility and aligns with the standardized schema format across the project.
14-16: Refined Tags Field Structure.
Thetagsfield has been updated so that each tag is encapsulated in an object with avaluekey rather than being a plain string. This improves consistency and allows for future expansion (e.g., adding additional tag metadata).schema/tests/data/project/negative/audience_undefined.yaml (2)
7-8: Standardized Name Field Update.
Thenamefield’s conversion into a list containing an object with avaluekey ensures consistency with similar schema definitions in the project. Verify that downstream processes and validations accommodate this new structure.
11-13: Consistent Tags Structure.
As with other schema files, the transformation of thetagsfield from a list of strings to a list of objects (each with avaluekey) improves data uniformity and future scalability.schema/tests/data/committee/negative/logo_null.yaml (2)
10-11: Unified Logo Name Structure.
Thelogo.namefield now leverages a list of objects with avaluekey, which is consistent with the new schema design. This promotes extensibility and standardization across different schema types.
14-16: Consistent Committee Tags Update.
The update of thetagsfield to use objects with avaluekey (instead of plain strings) ensures consistency with the schema changes in other parts of the project.schema/tests/data/project/negative/sponsors_empty.yaml (2)
9-10: Enhanced Name Field for Sponsors Schema.
The revision of thenamefield to a list that wraps the project name in an object with avaluekey aligns this file with the overall schema improvements. Ensure that any components processing this field are updated accordingly.
14-16: Refactored Tags Field for Sponsors Schema.
Transitioning thetagsfield to a list of objects each containing avaluekey improves consistency and allows for added extensibility in handling tag metadata.schema/tests/data/project/negative/social_media_empty.yaml (2)
9-10: Updated Name Field Structure.
The change to represent thenamefield as a list with an object holding avaluekey is consistent with the new common schema structure. This should help maintain uniformity across schema files.
14-16: Standardized Social Media Tags Field.
Thetagsfield now encapsulates each tag within an object (with avaluekey), ensuring consistency with other schema files and paving the way for potential attribute expansion in future iterations.schema/tests/data/chapter/negative/region_null.yaml (2)
8-9: StructurednameField Update.
Thenamefield now uses an array containing a dictionary with a keyvalueinstead of a plain string. This change aligns with the extracted common properties and standardizes the schema’s structure.
12-14: StructuredtagsField Update.
The transformation of thetagsfield into an array of objects (each with avaluekey) ensures consistency across schema definitions and sets the foundation for future extensibility.schema/tests/data/chapter/negative/meetup_group_null.yaml (2)
9-10: NestednameField Transformation formeetup_group.
Thenameproperty undermeetup_groupis now structured as an array containing a dictionary withvalue. This enforces consistency with the new common properties extraction.
12-14: StructuredtagsField Update undermeetup_group.
Thetagsfield has been updated to a list of dictionaries instead of strings, aligning with the overall schema update. Ensure that any schema validations or consumers referencing this field are updated accordingly.schema/tests/data/project/negative/demo_non_unique.yaml (2)
11-12: StructurednameField Update for Project Demo.
The shift from a plain string to an array containing an object (with keyvalue) for thenamefield promotes the use of common properties and supports further enrichment if needed.
15-17: StructuredtagsField Update for Project Demo.
Thetagsfield now stores its values within objects (each having avaluekey), ensuring consistency with the new schema design and allowing for potential future attribute additions.schema/tests/data/project/negative/social_media_null.yaml (2)
9-10: StructurednameField Update for Social Media Scenario.
Updating thenamefield to use an array with a dictionary containing thevaluekey reinforces schema uniformity across different test cases.
14-16: StructuredtagsField Update for Social Media Scenario.
The conversion oftagsfrom a simple list of strings to a list of objects with avaluekey is consistent with the overall design change. This update will help maintain consistency and facilitate future enhancements.schema/tests/data/chapter/negative/social_media_empty.yaml (2)
8-9: StructurednameField Update for Social Media (Empty) Case.
The change of thenamefield to an array containing a dictionary with avaluekey adheres to the newly established pattern for common properties, ensuring consistency in data representation.
12-14: StructuredtagsField Update for Social Media (Empty) Case.
Transforming thetagsfield into an array of dictionaries (each with avaluekey) standardizes the data structure across schema files and supports enhanced extensibility.schema/tests/data/committee/negative/resources_invalid.yaml (2)
9-10: Standardizing the "name" Field Structure.
The revised format now uses an array containing an object with the key"value", which aligns with the extracted common properties. This change improves consistency across schema definitions.
17-19: Standardizing the "tags" Field Structure.
Converting tags from a flat list of strings to an array of objects (each with a"value"key) enhances the schema’s extensibility and maintains consistency with similar changes elsewhere.schema/tests/data/committee/negative/description_null.yaml (2)
9-10: Updating the "name" Field to a Structured Format.
Changing the simple string representation ofnameinto an array with a single object containing a"value"key is in line with the new common schema properties. Ensure that schema validations and downstream processing are adjusted accordingly.
13-15: Updating the "tags" Field to a Structured Format.
Converting tags into an array of objects with a"value"key is consistent with the overall schema refactoring. Confirm that error messages and any validators reflect this updated structure.schema/tests/data/chapter/negative/sponsors_empty.yaml (2)
8-9: Adopting the Standardized Format for "name".
Updatingnameto an array containing an object with the"value"key aligns with the extracted common properties and ensures consistency with other schema files.
12-14: Adopting the Structured Format for "tags".
The conversion of tags to an array of objects using the"value"key is consistent with the new schema structure. Please verify that test cases expecting a flat list of strings are updated accordingly.schema/tests/data/committee/negative/members_undefined.yaml (2)
2-3: Converting the "name" Field to a Structured Format.
The change from a plain string to an array containing an object with a"value"key aligns with the newly extracted common properties. Ensure that validations and tests appropriately capture this updated structure.
6-8: Converting the "tags" Field to a Structured Format.
Updating tags to an array of objects (each holding a"value"key) maintains consistency with the schema-wide changes. Confirm that all consumers and error messages are updated accordingly.schema/tests/data/project/negative/repositories_non_unique.yaml (2)
9-10: Updating the "name" Field to the Standardized Structure.
The modification converts thenamefield from a simple string to an array containing an object with a"value"key, consistent with the refactored common schema properties. Validate that schema tests capture the updated data format.
16-18: Adopting the Structured Format for "tags".
Changing thetagsfield to an array of objects with a"value"key is in line with the overall schema extraction initiative. Please ensure that any validation logic (such as uniqueness constraints) is updated to work with this new structure.schema/tests/data/committee/negative/social_media_invalid.yaml (2)
9-10: StandardizenameField Structure.
Thenameproperty has been updated from a simple string to an array containing an object with avaluekey. This change is consistent with the new common schema design and improves future extensibility.
16-18: EnhancetagsField Format.
Transforming thetagsfield from a list of strings to an array of objects (each with avaluekey) aligns the data structure across schemas and facilitates potential expansion.schema/tests/data/project/negative/repositories_null.yaml (2)
9-10: StandardizenameField Representation.
Updating thenamefield to an array of objects with avaluekey adheres to the extracted common properties approach, ensuring consistency with other schema definitions.
14-16: StandardizetagsField Structure.
Convertingtagsto an array of objects rather than simple strings improves the flexibility of the schema and maintains uniformity across the project’s schema files.schema/tests/data/project/negative/social_media_non_unique.yaml (2)
8-9: RefinenameField Structure.
The change to representnameas a list containing an object with avaluekey is in line with the new schema pattern. Please verify that any uniqueness constraints (if applicable) are enforced.
17-19: UpdatetagsField to Object Format.
Transitioning from plain string entries to objects with avaluekey provides a more robust foundation for later enhancements and keeps the schema consistent.schema/tests/data/committee/negative/mailing_list_null.yaml (3)
2-2: Replace Deprecated Field withmailing_list.
The removal of the oldgroup_mailfield in favor ofmailing_liststandardizes the field names across schemas. Ensure that the corresponding schema definitions and validations have been updated accordingly.
10-11: Standardize CommitteenameField.
Changing thenameproperty to an array containing an object with avaluekey helps unify the schema design. Please confirm that all references reflect this updated structure.
14-16: Update CommitteetagsField Format.
Modifying thetagsfield to an array of objects with avaluekey increases consistency and allows for easier extension in future schema updates.schema/tests/data/chapter/negative/country_undefined.yaml (2)
7-8: Refine ChapternameField Structure.
Thenamefield is now represented as an array containing an object with avaluekey (holding "OWASP Chapter"), which aligns with the overall schema refactor.
10-12: Standardize ChaptertagsField Representation.
Updating thetagsfield to use objects with avaluekey improves data consistency across schema definitions. Double-check that any schema validations and references have been updated.schema/tests/data/project/negative/community_non_unique.yaml (2)
14-15: Structured “name” Field Update:
The “name” field is now defined as a list containing a dictionary with a keyvalue(e.g.- value: OWASP Incubator Code Project). This change is in line with the objective to standardize schema properties. Please verify that all consumers of this field are updated accordingly.
18-20: Structured “tags” Field Update:
The “tags” field has been converted from a plain list of strings to a list of objects with avaluekey. This improves extensibility and consistency across the schemas. Ensure that any schema validations or data processors expecting tags are adapted to this new format.schema/tests/data/project/negative/blog_null.yaml (2)
9-10: Standardized “name” Field Format:
The “name” field is now represented as a list with a dictionary (- value: OWASP Incubator Code Project). This update aligns with the common properties extraction goal. Confirm that tests expecting the old string format have been adjusted.
13-15: Standardized “tags” Field Format:
The tags structure has been updated to use objects with thevaluekey, e.g.- value: example-tag-1. This is consistent with similar changes elsewhere in the project. Remember to update any references that used the previous tag format.schema/tests/data/project/negative/type_empty.yaml (2)
9-10: Uniform “name” Field Representation:
The “name” field now uses the structured format as a list containing a dictionary (- value: OWASP Incubator Code Project). This change reinforces the consolidation of common properties and should be checked for consistency with validation logic.
13-15: Uniform “tags” Field Representation:
The transformation of the “tags” field to a list of objects with avaluekey enhances future extensibility of tag attributes. Ensure that any downstream processing or error messages consider this new structure.schema/tests/data/chapter/negative/name_empty.yaml (2)
7-7: Empty “name” Field as List:
Changing the “name” field from an empty string to an empty list (name: []) is a good move towards consistent data typing. This prevents type ambiguity and aligns with the new schema structure.
9-11: “tags” Field Structured Update:
The “tags” field has been revised from a list of strings to a list of objects containing avaluekey. This establishes consistency with other schema files and allows for future enhancements.schema/tests/data/chapter/negative/sponsors_non_unique.yaml (2)
8-9: Consistent “name” Field Update:
The “name” field now employs a structured format (- value: OWASP Chapter) similar to other schemas. Be sure that this change is reflected in any related sponsor-processing logic.
16-18: Consistent “tags” Field Update:
The update of the “tags” field to a list of objects with avaluekey improves schema uniformity. Validate that any tests or consumption of these tags from vendor or internal tools have been updated accordingly.schema/tests/data/project/negative/leaders_empty.yaml (2)
4-5: Structurednamefield update.
Thenamefield is now defined as a list containing a dictionary with avaluekey, aligning with the new common property extraction approach.
8-10: Updatedtagsfield structure.
Thetagsfield has been converted to a list of dictionaries (each with avaluekey), which improves consistency and allows for future extensibility in schema definitions.schema/tests/data/chapter/positive/required_properties.yaml (2)
8-9: Revisednameproperty structure.
The update converts thenameproperty from a plain string to a structured list with a dictionary containing thevaluekey, ensuring uniformity with the extracted common properties.
11-13: Standardizedtagsproperty format.
Thetagsfield now uses a list of dictionaries with avaluekey, which is consistent with the refactored schema design across the project.schema/tests/data/chapter/negative/website_empty.yaml (3)
8-9: Consistentnamefield format.
Thenameproperty has been updated to the new array format with a dictionary entry, ensuring consistency with the overall schema extraction initiative.
11-13: Refinedtagsfield standard.
Updating thetagsproperty to a list of dictionaries with avaluekey brings it in line with other schema files and enables potential future extensions.
14-14: Clarified emptywebsiterepresentation.
Changing thewebsitefield to an empty list rather than an empty string supports schema validation and maintains structural consistency.schema/tests/data/committee/negative/community_non_unique.yaml (2)
14-15: Updated committeenamefield.
Thenameproperty now follows the unified structure by using a list with a dictionary containing avaluekey, which improves consistency with other schema definitions.
18-20: Standardized committeetagsfield.
The change to structure thetagsfield as a list of dictionaries (with each entry using avaluekey) is aligned with the overall schema update, ensuring homogeneity across definitions.schema/tests/data/project/negative/downloads_empty.yaml (2)
3-4: Refactorednameproperty for projects.
Converting thenamefield to a list containing a dictionary with thevaluekey follows the common convention introduced in this PR, reinforcing schema consistency.
11-13: Revisedtagsproperty for projects.
Thetagsfield has been adapted to a structured representation (list of dictionaries with avaluekey), which aligns with the standardized schema format across the codebase.schema/tests/data/committee/negative/events_empty.yaml (2)
10-11: Updated schema format for the 'name' fieldThe name field has been converted from a simple string to an array of objects with a 'value' key, which aligns with the schema refactoring to extract common properties.
13-16: Consistent structure applied to 'tags' fieldGood change - the tags field now follows the same object-based structure as other properties in the schema, making it more consistent and extensible for future attributes.
schema/tests/data/project/negative/license_invalid.yaml (2)
7-8: Updated schema format for the 'name' fieldThis change matches the schema refactoring by moving from a direct string value to an array containing an object with a 'value' property.
10-13: Standardized 'tags' structure across schemasThe tags field now uses a consistent object-based structure with 'value' properties, which improves schema consistency across different entity types.
schema/tests/data/committee/negative/members_empty.yaml (2)
3-4: Updated schema format for the 'name' fieldThe name field has been properly converted to the new object-within-array structure, consistent with the schema standardization.
6-9: Consistent 'tags' structure implementationThe tags field now follows the new structure pattern with objects containing 'value' properties, which aligns with the goal of extracting common properties into a standardized format.
schema/tests/project_test.py (5)
63-64: Updated error message for events' non-unique validationThe error message correctly reflects the new structure of events as objects with a 'url' property instead of simple strings.
93-95: Type validation updated for mailing list fieldsThe error messages have been properly updated to validate against the new array type expectation instead of the previous URI type.
97-97: Type validation updated for name fieldError message correctly updated to check for array type in line with the schema changes.
125-127: Updated validation for non-unique tagsThe error message now accurately represents the validation against the new tag structure (objects with 'value' properties).
132-133: Type validation updated for website fieldsError messages correctly updated to validate against array types instead of strings, matching the schema changes.
schema/tests/data/chapter/negative/website_null.yaml (3)
5-7: Addition of New Leader Entry with Slack Identifier
The new leader entry (lines 5–7) now includes aslackproperty for Leader 2. This change aligns with the extraction of common properties and should be validated against the schema to ensure that theslackfield is optional where appropriate.
8-9: Updated 'name' Field to Structured Format
Thenamefield now uses an array that contains an object with avaluekey. This structural change is consistently applied across the schemas and enhances extensibility.
11-13: Revised 'tags' Field to Object Format
The update transforms the tags from plain strings into objects with avaluekey. Make sure the schema validation enforces any uniqueness or additional constraints as defined in the common properties.schema/tests/data/chapter/negative/region_empty.yaml (3)
8-9: Updated 'name' Field to Structured Format
Changing thenamefield to an array holding an object (with keyvalue) is a positive step toward a unified schema design. Verify that the validation rules reflect this updated structure.
12-14: Revised 'tags' Field to Object Format
Thetagsfield is now represented as objects instead of simple strings. This consistent approach across files supports future extensions and ensures uniform data handling.
10-10: Note on 'region' Field
Theregionfield remains as an empty string (line 10). Please ensure that the schema validation for this field correctly handles empty or undefined region values in negative test scenarios.schema/tests/data/project/negative/level_undefined.yaml (3)
1-7: Leader Entries Remain Consistent
The leader details from lines 1 to 7 remain unchanged. It’s good to see consistency here; just ensure that these entries are also validated against the updated common schema definitions.
8-9: Updated 'name' Field to Object Format
Converting the projectnamefield to an array of objects (each with avaluekey) ensures consistency with the new schema design. This change enhances flexibility for future metadata additions.
12-14: Revised 'tags' Field to Use Object Format
The changes to thetagsfield, now encapsulated in objects with avaluekey, are consistent with similar adjustments elsewhere. Verify that any schema test cases account for this new representation.schema/tests/data/project/negative/logo_empty.yaml (3)
10-11: Updated 'name' Field to Structured Format
Thenamefield is now defined as an array with an embedded object containing thevaluekey. This approach adheres to the project's move toward extracting common properties and should be validated accordingly.
14-16: Revised 'tags' Field to Object Format
Transforming thetagsentries into objects with avaluekey promotes uniformity. Make sure that these changes are reflected in corresponding schema rules and test validations.
8-9: Verification for 'logo' Field Representation
Thelogofield (line 9) remains an empty array. Verify that this empty representation is acceptable per the schema definitions for cases where no logo is provided.schema/tests/data/committee/negative/mailing_list_empty.yaml (3)
2-2: Renamed and Initialized 'mailing_list' Field
Replacing the previousgroup_mailwithmailing_list(line 2) and initializing it as an empty array aligns with the centralized common properties approach. Confirm that the schema accepts this field type and structure.
10-11: Updated 'name' Field to Structured Format
Thenamefield now follows the new pattern by being an array of objects with avaluekey. This change supports improved consistency across committee schema definitions.
14-16: Revised 'tags' Field to Object Format
The updated structure fortagsas objects (each with avaluekey) is consistent with the changes made in other parts of the project. Ensure that any uniqueness or format validations are updated accordingly.schema/tests/data/project/negative/audience_empty.yaml (2)
8-9: Structured "name" Field Update.
Thenamefield is now defined as a list containing a dictionary with the keyvalue. This aligns with the refactoring goal of extracting common properties and makes the schema more extensible. Please ensure that any downstream processing expecting a plain string is updated accordingly.
12-14: Revised "tags" Field Structure.
Thetagsfield has been transformed into a list of dictionaries (with each dictionary having avaluekey), which standardizes the schema across the project. This change enhances consistency and future extensibility.schema/tests/data/project/negative/level_invalid.yaml (2)
8-9: Standardized "name" Field Format.
The update to define thenamefield as an array with an inner dictionary containingvaluemeets the objectives of extracting common schema properties. Confirm that all validators or consumers of this field are compatible with this new structure.
12-14: Consistent "tags" Field Transformation.
Changing thetagsfield to a list of objects with avaluekey is consistent with the refactored schema design. Please verify that this structured approach is uniformly supported throughout the codebase.schema/tests/data/project/positive/required_properties.yaml (2)
9-10: Refined "name" Field Format.
Thenameproperty now uses an array with a dictionary containing thevaluekey, which adheres to the common property extraction strategy. This structured format enhances consistency across schema files.
13-15: Transformed "tags" Field Structure.
The conversion of thetagslist to a list of dictionaries (each with avaluekey) promotes uniformity and supports potential future metadata additions. The implementation looks correct and consistent.schema/tests/data/committee/negative/meeting_minutes_invalid.yaml (2)
12-13: Updated "name" Field for Meeting Minutes.
Thenamefield is updated to follow the structured format (list containing a dictionary withvalue), aligning it with the new common schema design. Ensure that any components referencing this field are aware of the change.
16-18: Revised "tags" Field Structure.
The transformation of thetagsfield into an array of objects with avaluekey is consistent with the project's schema refactoring efforts. This update improves clarity and extensibility.schema/tests/data/project/negative/website_null.yaml (2)
6-7: Structural Update for "name" Field.
The change to define thenamefield as an array of dictionaries with avaluekey follows the common properties extraction approach. Verify that any data consumers have been updated to handle this structured format.
10-12: Revised "tags" Field Format.
Thetagsfield now correctly follows the new structure by using dictionaries with avaluekey for each tag. This is consistent with the modifications across other schema files.schema/tests/data/committee/negative/sponsors_null.yaml (2)
9-10: Structured "name" Field UpdateThe
namefield is now represented as a list containing an object with avaluekey. This change aligns with the extraction of common properties for schema definitions, ensuring consistency across the project.
14-16: Refined "tags" Field StructureThe
tagsfield has been updated to include objects with avaluekey instead of plain strings. This structured representation promotes uniformity and ease of extension in future schema enhancements.schema/tests/data/committee/negative/social_media_null.yaml (2)
9-10: Enhanced "name" Field ConsistencyThe change to the
namefield—transforming it into a list containing an object with avaluekey—ensures that the schema for committee entities maintains a consistent structure with other schema files.
14-16: Standardized "tags" Field FormatThe modification of the
tagsfield to a list of objects, each having avaluekey, is in line with the broader schema extraction effort. This update improves clarity while supporting future extension of tag properties.schema/tests/data/chapter/negative/country_null.yaml (2)
8-9: Updated "name" Field StructureTransforming the
namefield into a list with a single object containing thevaluekey increases consistency with the common properties extracted across schemas. This change is well-justified from a design standpoint.
11-13: Unified "tags" Field RepresentationThe update to the
tagsfield—where each tag is encapsulated as an object with avaluekey—ensures uniform data handling and aligns with the project’s goal of reducing redundancy through common property extraction.schema/tests/data/chapter/negative/community_non_unique.yaml (2)
13-14: Consistent "name" Field FormattingThe revision of the
namefield to a list containing an object with avaluekey promotes a standardized format across schema definitions. This approach enhances both readability and maintainability.
16-18: Harmonized "tags" Field UpdateConverting the
tagsfield to a structured format using objects with avaluekey not only aligns with the new schema standards but also simplifies future enhancements and validations.schema/tests/data/chapter/negative/leaders_undefined.yaml (2)
2-3: Refined "name" Field DesignChanging the
namefield from a simple scalar to a list of objects with avaluekey improves the schema's consistency and prepares it for potential future extensions.
5-7: Revised "tags" Field StructureUpdating the
tagsfield to a list of objects with avaluekey—rather than plain strings—ensures that all schema components follow the same design pattern, which simplifies maintenance and validation.schema/tests/data/chapter/negative/social_media_null.yaml (2)
8-9: Structured 'name' Field Revision
The change from a simple string to a list containing an object with the keyvalueenhances extensibility and consistency across the schemas. Please verify that all consumers of this field expect and correctly process the new structured format.
12-14: Standardized 'tags' Field Structure
Transforming simple string tags into objects with avaluekey aligns with the overall schema improvements. Ensure that downstream validations and processing logic are updated to handle this nested structure appropriately.schema/tests/data/committee/negative/sponsors_empty.yaml (2)
9-10: Convert 'name' Field to Structured Format
Changing thenamefield from a scalar to an array of objects (withvalue) increases consistency with other schema definitions. Confirm that both front-end and back-end validations are adjusted to process arrays instead of plain strings.
14-16: Revise 'tags' Field for Improved Structure
The update of the tags field to a list of objects with avaluekey standardizes the data format. Make sure that any code referencing the tags is updated to traverse this structure, ensuring seamless integration.schema/tests/data/committee/negative/community_null.yaml (2)
10-11: Updated 'name' Field Representation
The modification of thenamefield into a structured array with avaluekey is consistent with the new schema guidelines. Verify that schema validators and any related processing pipelines are aware of this new format.
13-16: Standardized 'tags' Structure
Adopting a structured format for thetagsfield helps maintain consistency across schemas. Ensure that any module or client consuming these tags is updated to handle objects rather than simple strings.schema/tests/data/committee/negative/description_undefined.yaml (2)
8-10: Duplicate 'name' Field Entries in Negative Test
The conversion of thenamefield into an array with two identical entries (OWASP Committee) appears to be intentional for negative testing, potentially to validate uniqueness constraints. Confirm that the schema correctly flags duplicates if required by your validation rules.
13-15: Standardized 'tags' Field Structure
As with the other files, updating the tags to objects with avaluekey ensures consistency. Double-check that the test expectations align with this structured approach and that any unique item constraints are enforced.schema/tests/data/committee/negative/website_empty.yaml (3)
9-10: Structured 'name' Field Update
Updating thenamefield to a list containing an object with the keyvalueis consistent with the new schema design. Please verify that this change is properly documented and handled throughout the system.
13-15: Standardized 'tags' Field Update
The conversion of thetagsfield to use objects with avaluekey enhances consistency across the schema definitions. Make sure any tag-related processing logic is adjusted accordingly.
16-16: 'website' Field Structure Change
Changing thewebsitefield from an empty string to an empty list aligns with the structured format applied to similar fields. Confirm that any validation or rendering logic expecting a website field correctly handles an empty array.schema/tests/data/committee/negative/website_null.yaml (2)
9-10: Name Field Format Update:
Thenamefield is now represented as a list containing an object with avaluekey. This change aligns with the extraction of common properties, ensuring consistency across schema definitions.
13-15: Tags Field Structure Update:
Thetagsfield has been updated to a list of objects with avaluekey, enhancing the uniformity and extensibility of tag representations throughout your schemas.schema/tests/data/committee/positive/required_properties.yaml (2)
9-10: Updated Name Field:
Thenamefield has been restructured to a list containing an object with avalueattribute. This update is consistent with the common properties extraction, streamlining the schema definitions.
13-15: Standardized Tags Field:
The conversion of thetagsfield into a list of objects with avaluekey maintains consistency with similar schema updates across the project, thereby reducing redundancy in property definitions.schema/tests/data/committee/negative/events_null.yaml (2)
10-11: Name Field Transformation:
The update converting thenamefield into a list with an embeddedvaluekey aligns perfectly with the new common property structure, improving schema uniformity.
14-16: Tags Field Restructuring:
Transitioning thetagsfield into a list of objects withvaluekeys facilitates consistent data validation and future extensibility.schema/tests/data/chapter/negative/meetup_group_empty.yaml (2)
9-10: Revised Name Format:
Thenamefield update to a list containing an object with avaluekey is in line with the extracted common properties. This standardizes the field format across different schema files.
12-14: Refined Tags Structure:
The change to represent thetagsfield as a list of objects with avaluekey ensures consistency and simplifies any future modifications or validations.schema/tests/data/chapter/negative/country_empty.yaml (2)
8-9: Name Field Update:
Changing thenamefield to a list with avaluekey adheres to the consolidated common properties approach, making the data structure more uniform and easier to manage.
11-13: Tags Field Update:
The updated structure for thetagsfield, now as a list of objects with avalueattribute, is consistent with the new schema conventions designed to improve maintainability.schema/tests/data/project/negative/documentation_non_unique.yaml (2)
12-13: Standardize 'name' Field Format
Thenamefield is now expressed as a list containing an object with thevaluekey. This change aligns well with the common properties extraction objective. Please verify that all consumers of this field have been updated to accommodate the new structure.
16-18: Ensure Consistent 'tags' Field Structure
Thetagsfield has been transformed from a plain list of strings to a list of objects, each with avaluekey. This promotes consistency across schemas. Make sure that any validations or processing logic expecting tag entries handle the nested object format correctly.schema/tests/data/chapter/negative/leaders_non_unique.yaml (2)
5-6: Adopt Uniform 'name' Field Structure in Leaders Schema
The update to thenamefield, converting it to a list with avaluekey, is consistent with the extraction of common schema properties. Confirm that any existing rules or validations referencing this field are adjusted accordingly.
8-10: Align 'tags' Field with Common Structure
Transforming thetagsfield into a list of objects with avaluekey enhances consistency. Ensure that downstream processes and validation logic that check for tag uniqueness or content have been reviewed in light of this change.schema/tests/data/committee/negative/name_empty.yaml (2)
9-9: Convert Empty 'name' Field to Array Format
Changing thenamefield from an empty string to an empty array is a proper move to maintain a consistent data type. Confirm that the validation logic and error messages properly handle an empty list for thenamefield.
12-14: Standardize 'tags' Field Representation
Thetagsfield has been updated from plain string values to objects with avaluekey. This uniform structure should simplify handling across different parts of the codebase. Verify that tests reflect this updated structure.schema/tests/data/committee/negative/community_empty.yaml (2)
10-11: Apply Structured Format for 'name' Field
The change to represent thenamefield as a list containing an object with avaluekey is in line with the schema consolidation efforts. Ensure that any logic relying on thenamefield correctly interprets this new format.
14-16: Revise 'tags' Field to Match Common Schema Pattern
By updating thetagsfield to a list of objects each containing avaluekey, the schema becomes more extensible and consistent. Please double-check that tag validations and uniqueness constraints are still functioning properly after this change.schema/tests/data/chapter/negative/events_null.yaml (2)
9-10: Update 'name' Field Structure for Events Schema
Transforming thenamevalue into an array with avaluekey aligns with the standardized approach for common properties. Ensure that any consumers processing the event details are aware of the new data structure.
12-14: Modernize 'tags' Field Format in Events Schema
The revision of thetagsfield to include objects with avaluekey (instead of plain strings) enhances the schema's consistency and potential extensibility. Make sure that tests and validation rules are adjusted to accommodate this new format.schema/tests/data/chapter/negative/blog_null.yaml (2)
8-9: Refactor thenameField Structure
Thenamefield is now represented as an array containing an object with avaluekey, which aligns with the new common property extraction approach. This change facilitates future extensibility in the schema.
11-13: Refactor thetagsField Structure
Changingtagsfrom a list of plain strings to a list of objects (each with avaluekey) ensures consistency with the updated schema design, enhancing clarity and maintainability.schema/tests/data/chapter/negative/events_empty.yaml (2)
9-10: Update thenameField Format
The modification of thenamefield to an array containing a structured object (- value: OWASP Chapter) mirrors the new convention for shared schema properties. This will help enforce a consistent data format across the project.
12-14: Update thetagsField Format
Transforming thetagsfield into an array of objects with avaluekey ensures that the schema definitions are uniform. This change makes the property more adaptable for potential future enhancements.schema/tests/data/project/negative/pitch_null.yaml (2)
9-10: Standardize thenameField Structure
By converting thenamefield to an array containing an object with thevaluekey, this update enforces the common structure extraction, ensuring consistency with other schema files.
13-15: Standardize thetagsField Structure
The update of thetagsfield to use objects with avaluekey (instead of plain strings) aligns with the broader refactoring effort, thereby improving overall schema consistency and future-proofing the design.schema/tests/data/project/negative/events_null.yaml (2)
3-4: Refactor thenameField Definition
Changing thenamefield into an array that encapsulates a structured object (- value: Test Project) supports the consolidated schema property design, promoting uniform handling across different files.
11-13: Refactor thetagsField
Converting each entry in thetagsfield to an object with avaluekey helps maintain consistency with the common properties pattern. This change enhances schema clarity and reduces redundancy.schema/tests/data/project/negative/pitch_undefined.yaml (2)
9-10: Update thenameField Format
Thenamefield now uses an array format with a dictionary containing avaluekey. This update supports the extracted common properties design, ensuring consistency with other schema definitions.
12-14: Update thetagsField Format
Adopting a structured object (with avaluekey) for each tag in thetagsfield maintains uniformity with the new schema design and simplifies data validation in downstream tests.schema/tests/data/project/negative/mailing_list_empty.yaml (2)
9-10: Name structure update matches schema changes.The change from a simple string to an array containing an object with a
valueproperty aligns with the PR's objective of extracting common properties across schemas.
12-15: Tags structure update matches schema changes.The change from simple string tags to objects with a
valueproperty is consistent with the schema restructuring across the project.schema/tests/data/project/negative/demo_empty.yaml (2)
9-10: Name structure update matches schema changes.The change from a simple string to an array containing an object with a
valueproperty aligns with the PR's objective of extracting common properties across schemas.
12-15: Tags structure update matches schema changes.The change from simple string tags to objects with a
valueproperty is consistent with the schema restructuring across the project.schema/tests/committee_test.py (4)
28-30: Updated error message accurately describes non-unique events.The error message has been updated to reflect the new structure of event items as objects with URLs.
32-33: Field renaming from 'group_mail' to 'mailing_list'.The test case names and error messages have been updated to reflect a field renaming from 'group_mail' to 'mailing_list'. This naming is more intuitive and aligns with common terminology.
50-50: Updated error message for empty name array.The error message has been updated to reflect that 'name' is now expected to be a non-empty array instead of a string.
65-66: Updated website validation messages.The error messages for website validation have been updated to reflect the new array-based structure.
schema/tests/data/project/negative/community_empty.yaml (2)
10-11: Name structure update matches schema changes.The change from a simple string to an array containing an object with a
valueproperty aligns with the PR's objective of extracting common properties across schemas.
13-16: Tags structure update matches schema changes.The change from simple string tags to objects with a
valueproperty is consistent with the schema restructuring across the project.schema/tests/data/project/negative/sponsors_null.yaml (2)
9-10: StructurednameField Update.
The change from a plain string to a list containing a dictionary with the keyvalueis correctly implemented, ensuring consistency with the new schema design.
14-16: StructuredtagsField Update.
Changing the tags into objects with avaluekey enhances the clarity and maintainability of the schema. Ensure that any validations or downstream processing acknowledge the new structure.schema/tests/data/project/negative/mailing_list_invalid.yaml (2)
9-10: ReformattingnameField.
Transitioning the project name to a structured format (an array of objects withvalue) is consistent with the broader schema updates. Confirm that all test cases expecting a simple string are updated accordingly.
13-15: ReformattingtagsField.
Updating the tags to be formatted as a list of dictionaries withvaluekeys is appropriate for enforcing consistency within the schema.schema/tests/data/project/negative/type_undefined.yaml (2)
9-10: StandardizednameField Structure.
Converting the plainnameinto an array of objects with avaluekey adheres to the updated schema standards.
13-15: StandardizedtagsField Structure.
The update of thetagsfield to use dictionaries withvaluekeys is consistent and improves data clarity.schema/tests/data/committee/negative/resources_null.yaml (2)
9-10: CommitteenameField Enhancement.
The structured update for the committee’snamefield—now a list with avaluekey—ensures consistency with the rest of the schema definitions and supports future extensibility.
14-16: CommitteetagsField Update.
The new format for tags as objects with avaluekey adequately standardizes the representation across schemas.schema/tests/data/chapter/negative/sponsors_null.yaml (2)
8-9: ChapternameField Restructuring.
The change to convert the chapter name into a structured list format with avaluekey is consistent with schema-wide updates, improving overall data uniformity.
12-14: ChaptertagsField Restructuring.
The modification of tags into a list of dictionaries withvaluekeys improves clarity; ensure all consuming systems reflect this change.schema/tests/data/project/negative/type_null.yaml (1)
13-15: Structured Conversion of the "tags" Field
The update of thetagsproperty to use a list of dictionaries (each with avaluekey) is consistent with the new common property extraction effort and enhances clarity.schema/tests/data/project/negative/blog_invalid.yaml (2)
9-10: Update of the "name" Field Structure
Converting thenamefrom a simple string to an array containing an object with avaluekey aligns nicely with the extracted common properties. This improves the readability and future scalability of the schema.
13-15: Refinement of the "tags" Field Structure
The structured transformation of thetagsfield to a list of objects with avaluekey is implemented correctly and is consistent with other schema changes.schema/tests/data/committee/negative/scope_null.yaml (2)
9-10: Consistent Structuring of the "name" Field
Changing thenamefield to use a list with a keyvalueimproves consistency across the schemas. This modification is well aligned with the objective of extracting common properties.
13-15: Standardization of the "tags" Field
The update to thetagsfield, converting each tag into an object with avaluekey, ensures uniformity and allows future metadata expansion.schema/tests/data/project/negative/demo_null.yaml (2)
9-10: Refined "name" Field Representation
The conversion of thenamefield from a plain string to a structured format (list containing an object with avaluekey) is clear and helps standardize schema definitions across the project.
13-15: Refined "tags" Field Representation
The transformation of thetagsfield to a structured list of dictionaries is well executed and adds to the overall consistency of the schema.schema/tests/data/project/negative/community_null.yaml (2)
10-11: Enhanced "name" Field Structuring
The change from a simple string to a structured list element with avaluekey for thenamefield is consistent with the new schema design. This approach is forward-looking and improves maintainability.
14-16: Consistent Update for the "tags" Field
Updating thetagslist to comprise objects with avaluekey standardizes the format across different schema files. This consistency is crucial for reducing redundancy and streamlining validation logic.schema/tests/data/committee/negative/sponsors_invalid.yaml (2)
9-10: Updated "name" Field Structure
The "name" field is now defined as an array containing an object with a "value" key. This change aligns with the common schema extraction, ensuring consistency across definitions.
16-18: Reformatted "tags" Field
The "tags" property has been updated to a structured format where each tag is represented as an object with a "value" key, in line with the new common properties.schema/tests/data/committee/positive/optional_properties.yaml (4)
10-11: Refactored "events" Field
The events array now encapsulates each URL within an object keyed by "url" to adhere to the structured common property format.
26-27: Updated "name" Property
The "name" field has been transformed into an array containing an object with a "value" key. Ensure that any downstream consumers are updated to handle this structured format.
44-46: Structured "tags" Field
The tags are now defined as a list of objects with a "value" key, ensuring uniformity with other schema sections.
47-49: Enhanced "website" Structure
The website field now consists of a list containing objects with both "description" and "url" properties, which improves clarity and consistency.schema/tests/data/committee/negative/events_non_unique.yaml (3)
3-4: Duplicate "events" Validation Test
This negative test case intentionally includes duplicate event entries to verify that the uniqueItems constraint is correctly enforced in the schema.
12-13: Revised "name" Field Structure
The "name" field now follows the common pattern by using an array with an object that contains a "value" key, ensuring consistency with other schema files.
16-18: Updated "tags" Structure for Negative Testing
The tags are now expected as objects with a "value" key. This test ensures that non-compliant inputs (if any) are rejected per the schema's uniqueItems constraint.schema/committee.json (6)
41-43: Enhanced Member Name Constraints
Within the definitions, the member "name" now enforces a minimum length of 3 and a defined type of string. This helps improve data quality.
87-95: Refined "events" Definition
The "events" property now explicitly references the common event definition and includes constraints such as a minimum item count and uniqueness.
105-113: Added "mailing_list" Property
A new "mailing_list" property has been introduced with its definition referencing the common schema. This consolidation aids in reducing redundancy and improving maintainability.
131-140: Refactored Committee "name" Field
The "name" property for the committee is now restructured as an array containing exactly one item (referencing common.json#/definitions/name) while enforcing uniqueness.
193-201: Updated "tags" Field
The "tags" property now requires a minimum of three unique tag objects, with each item defined via the common schema reference.
202-210: Revised "website" Property
The "website" field has been reformatted as an array with a unique website object, ensuring consistency with the structured definitions across the project.schema/chapter.json (10)
17-18: Explicit "community" Definition
The "community" property now explicitly specifies its type as "array" along with the uniqueItems constraint, ensuring proper structure for community platforms.
26-34: Updated "events" Property
The events field is redefined to use the common event definition, with clear array constraints (minItems and uniqueItems) and an updated description.
35-43: Refined "leaders" Field
By explicitly defining "leaders" as an array with unique entries, this change ensures that the chapter's leadership information is consistently structured.
44-53: Standardized "logo" Property
The "logo" field is now clearly marked as an array with unique items, aligning it with the revised schema strategy for handling logos.
59-68: Transformed "name" Property
The "name" field has been converted into an array that must contain exactly one object (referencing the common definition), ensuring consistency across the schema.
74-82: Updated "social_media" Field
The social media information is now explicitly defined as an array with unique entries, which maintains consistency with other multi-value fields.
83-91: Revised "sponsors" Field
The "sponsors" property now includes an explicit array type and uniqueItems constraint, standardizing its structure with similar fields in the schema.
92-100: Refined "tags" Structure
The tags are now represented as an array of objects (referencing the common tag definition) with a requirement of at least three unique items. This change reinforces data consistency.
101-109: Enhanced "website" Field
The "website" property has been updated to an array format with a uniqueness requirement, referencing the website definition from the common schema for improved consistency.
111-116: Clarified Required Fields Block
The "required" array is reformatted to improve readability. Verify that all critical properties are indeed listed as required for complete validation.schema/project.json (13)
9-13: Audience Enum Update:
The updated enum for theaudienceproperty now clearly specifies the allowed values ("breaker", "builder", "defender"). This format is consistent with the schema-wide effort to standardize enumerated values.
32-33: Community Property as Array:
Thecommunityproperty now explicitly defines its type as"array"withuniqueItemsset to true. This change aligns with the new schema design, ensuring that community entries are handled uniformly.
41-44: Demo Property Array Conversion:
Defining thedemoproperty as an array with a minimum of one item and unique values ensures that multiple demo URLs can be provided in a structured manner while enforcing uniqueness.
67-74: Events Property Array Standardization:
Theeventsproperty now explicitly sets its type as"array", ensuring that event references (via$refto the common definition) are properly collected and unique.
82-83: Leaders Property as Array:
Enforcing theleadersproperty as an array (with the minimum items and uniqueness constraints) supports a consistent data structure for project leadership entries.
88-99: Level Property Enum Enhancements:
The update to thelevelproperty includes revised enum values and corresponding descriptions. This provides a clearer categorization of project maturity levels.
134-141: Mailing List Property Standardization:
Themailing_listproperty now leverages a common definition via$refand is defined as an array with unique items. This promotes consistency with similar properties across the schema.
142-151: Name Property Structured as Single-Item Array:
Converting thenameproperty from a simple string to an array—with explicitminItems,maxItems, and uniqueness constraints—aligns it with the overall normalization strategy. Verify that this approach meets your design requirements, as it may add an extra layer of complexity for a value that is typically singular.
166-173: Social Media Property Array Enforcement:
The update to thesocial_mediaproperty explicitly sets its type to"array", ensuring that social media entries are structured consistently with other similar fields.
184-189: Tags Property Alignment with Common Definition:
The change in thetagsproperty—now referencing a common definition—ensures that tags follow a standardized structure across the project schemas.
193-200: Project Type Enum Update:
Thetypeproperty is now constrained to accept only"code","documentation", or"tool", which enforces stricter data consistency and clarifies the project categorization.
207-214: Website Property Array Conversion:
Thewebsiteproperty has been restructured to be an array with unique items and now references the common definition. This change supports flexibility in handling multiple URLs while maintaining consistency.
217-225: Required Fields Formatting Update:
The updated"required"section now appears cleaner and more structured. Ensure that all mandatory fields—including those that have been converted to array types—are appropriately listed to meet validation expectations.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
schema/tests/data/chapter/negative/tags_non_unique.yaml (1)
10-13: Testing Non-Unique 'Tags' Entries
This negative test case now provides duplicate tag objects (all having"value": "example-tag-1"). If your schema is intended to enforce uniqueness of tags, ensure that the validation logic properly rejects this input. Otherwise, if non-unique tags are allowed by design, consider updating the test description for clarity.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
schema/common.json(8 hunks)schema/tests/chapter_test.py(3 hunks)schema/tests/common/website_test.py(1 hunks)schema/tests/data/chapter/negative/tags_non_unique.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- schema/tests/common/website_test.py
- schema/tests/chapter_test.py
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Run frontend e2e tests
- GitHub Check: CodeQL (python)
- GitHub Check: CodeQL (javascript-typescript)
🔇 Additional comments (9)
schema/common.json (8)
16-20: Enumeration Values for Community Platform Updated
The"platform"property now explicitly restricts values to"discord"and"slack", which is consistent with the intended domain.
28-31: Community Required Fields Updated
The changes ensure that"platform"and"url"are marked as required. This enforces consistency and proper validation for community objects.
35-60: New 'Event' Object Definition Added
The new"event"definition is well structured. It requires a"url"and includes additional properties with sensible constraints (e.g."minLength": 10for"description"and"title"). This aligns with the overall effort to extract common schema properties.
89-97: Potential Copy-Paste Issue in Mailing List Property Description
The inner"description"for the"mailing_list"definition currently reads"Description of mailing list". This wording might be a copy‐paste error. Consider revising it for clarity—for example:- "description": "Description of mailing list", + "description": "A brief description of the mailing list",This change would improve clarity and align the description with similar object definitions.
111-131: New 'Name' Object Definition is Well-Structured
The"name"definition now enforces the presence of a"value"property and provides a clear description. This improves consistency across schema definitions.
218-226: Social Media Platform Enum Defined Appropriately
The"platform"property within"social_media"now uses an enum with the values"bluesky","linkedin","x", and"youtube". This is consistent with our data validation goals.
273-293: Tag Object Definition is Clear and Consistent
The"tag"definition properly requires the"value"field and sets a minimal length for valid entries. This change fits well with the overall schema improvements.
294-315: Website Object Definition is Correctly Formatted
The"website"definition includes the necessary properties and validation constraints, maintaining consistency with other object definitions in the schema.schema/tests/data/chapter/negative/tags_non_unique.yaml (1)
8-9: 'Name' Field Transformation Verified
The transformation of the"name"field to an array containing an object with the"value"key aligns with the updated schema design.
|
@arkid15r I have made necessary changes, also wrote the tests covering common properties , let me know if any changes are required or any suggestions that are to be implemented :) |
Dishant1804
changed the title
| @@ -1,15 +1,16 @@ | |||
| country: India | |||
| events: | |||
| - https://example.com/event1 | |||
| - https://example.com/event1 | |||
| - url: https://example.com/event1 | |||
There was a problem hiding this comment.
@arkid15r i think we should keep the events as it is here as events can have title and urls as well, so creating a common definition of it might help here as it is used in multiple schema files, the title will also provide a better context to the url is what i thought.
Let me know how we want to proceed with it
|
@Dishant1804 any progress on fixing this (I'm working on reducing the PR queue)? |
I'm working on it, I'll complete it by today |
Dishant1804
force-pushed
the
schema_improvement
branch
from
8d83188 to
07aa3cd
Compare
|
Resolves #993