Repository navigation
fix: Validate the order by names of the entity queries - #48
Conversation
- The entity manager validates every name of the order by, as for filters - Create filter ignores sort values that are not attributes of the entity - Unknown sort values (eg: from translated pages) keep the default order - Tests cover the identifier values, unknown names and relation paths
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe MVC filter validates requested sort fields against entity attributes and eager-loaded relations. Invalid or unavailable fields retain the configured order. The entity manager validates relation paths and attribute names. Tests cover sorting, reference resolution, and nested relation filters. ChangesEntity query sort and relation validation
Priority: ➖ Normal Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to The change validates query names while preserving default sorting for invalid requests. No actionable merge-blocking issue remains; merge after normal checks pass. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The change strengthens sort-field validation and preserves configured ordering for unsupported input. No introduced authorization bypass was established. Remaining uncertainty concerns whether applications share mutable query defaults across requests and how relation registrations are governed. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Resilience and Maintainability Implications
Hardening Proposals
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 5.88% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 34 functions across 5 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3cde856cb5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Order by names through data references validate against the real class - Reserved names, such as the modification time, are valid sort values - Relation paths of filters resolve data references, keeping their values - Tests cover resolved, nested and unresolved data references
Closes #47, the client side being hivesolutions/uxf#40.
Cause
The sort value of a request (
sortororder) is turned bycreate_filterinto the order by of the query, and_resolve_namewrote its names into the order by clause without checking them, unlike the names of the filters, which are validated with_validate_name. An unknown name, such as the translated markup sent by the UXF filter of a page translated by the browser (OMNI-LDJ-15), reached the database as it was, failing the query with a syntax error and the request with an internal error. Unknown relation names of a dotted path were written as well, asget_relationreturns an empty descriptor for them.Changes
_resolve_name(data/src/entity_manager/system.py, only called by_order_query_f): validates each relation name of the path against the class it belongs to and the final name against the target class of the relation, raisingValidationErrorfor unknown names. Data references in the path are resolved into their real classes throughget_entity(), as the joins do, raisingValidationErrorwhen one is not resolved (the relation is not joined in that case)._class_create_filter(mvc/src/mvc_utils/entity_model.py): the sort value of the request is used only when it is__default__,__identifier__, a reserved name (_classand_mtime, as in the entity manager) or a name of the entity (or of an eager loaded relation, for dotted names), otherwise the default order is kept, as already done for the filters of relations that are not eager loaded. The order by is now built after the eager relations of the request are merged, so that a relation requested througheagercan still be sorted by.resolve()(inner function of_class_create_filter): resolves the data references of the path into their real classes at every level, keeping the reference when it is not found. Besides the sorting, this makes the filters through data references cast their values with the real class, which previously discarded them (None) for the attributes not declared in the reference.MockEntityManager,MockEntity,MockAddress,MockAddressReference,MockPerson,MockPersonReferenceandMockCompanyinmvc/src/mvc_utils/mocks.py.Verification
test_order_by_identifier,test_order_by_invalid,test_order_by_reservedandtest_order_by_referencein the entity manager, and the newCreateFilterTestCase(9 tests) in the MVC utils.test_order_by_invalidfails against the previous code (no such column: _person.unknown, the name reaching SQLite),test_order_by_referencefails without the resolution of the data references (attribute does not exist in 'Address', validated against the reference), as do 6 of theCreateFilterTestCasetests, and all of them pass with the change.black --checkclean.primary_contact_information.email) all have the relation eager loaded when the filter is created, so they keep being accepted.