Resolves issue #1714 , Refactoring reports_to for dynamic calculation and securing oversees updates.

[david-rocca]

Closes Issue #1714

Summary

This pull request refactors the organization hierarchy system by removing reports_to from database persistence and dynamically calculating it on-the-fly when reading organization data. Direct API modification mapping has been restricted, ensuring only oversees is edited and primarily by Secretariat roles. This eliminates manual synchronization efforts to keep parent-child relationships intact and locks down unauthorized assignment tracking.

Important Changes

src/model/baseorg.js

• Cleaned the code by dropping reports_to: String from the db Mongoose Schema.

src/middleware/schemas/BaseOrg.json

• Removed reports_to UUID mapping requirements from the database-layer JSON Schema validation.

schemas/registry-org/create-registry-org-request.json
schemas/registry-org/update-registry-org-request.json

• Completely removed reports_to expectations from internal/external JSON specifications preventing incorrect swagger usages.

src/controller/org.controller/org.middleware.js

• Blocklist setup: transitioned reports_to out of registryOnly queries into the isNotAllowed restrictions arrays across creations and updates, catching it pre-validation if supplied.

src/controller/registry-org.controller/index.js
src/controller/org.controller/index.js

• Added the express-validator directive body(['reports_to']).not().exists().withMessage('reports_to must not be present') forcing strict HTTP 400 rejection across all registryOrg and registry/org PUT and POST routes when attempting to directly supply reports_to.

src/controller/registry-org.controller/registry-org.middleware.js

• Dropped reports_to mapping from memory queries during incoming POST/PUT evaluations.

src/repositories/baseOrgRepository.js

• Refactored getOrg to dynamically run a manual BaseOrgModel.findOne({ oversees: result.UUID }) lightweight fetch and inject it back as reports_to gracefully on-the-fly.
• Mapped a native MongoDB pipeline $lookup hook inside setAggregateRegistryOrgObj querying the same relationship matching algorithm into arrays alongside a $cond that injects the variable dynamically.

test/integration-tests/registry-org/registryOrgCRUDTest.js

• Set up positive assertion flows ensuring sub-organization fetches pull reports_to cleanly via Secretariat's oversees edits.
• Created robust negative assertion tests predicting standard reports_to must not be present validator failures when users directly target the parameter during creation/update testing phases.

Testing

Steps to manually test updated functionality, if possible

• 1) Authenticate as a Secretariat user.
• 2) Create a sub-organization.
• 3) Update an overarching organization to encompass the sub-organization's UUID into its oversees array vector string.
• 4) Fire a generic GET request calling for the newly assembled sub-organization's metadata.
• 5) Verify its reports_to field parses gracefully with the UUID of the overarching organization.
• 6) As any user, ping a POST/PUT endpoint dropping the identifier reports_to into your HTTP requests payload, and evaluate a quick 400 Bad Request error.

Notes

• If downstream automated scripts were utilizing direct manual manipulation for tracking .reports_to, they must now switch to configuring parent entities leveraging the oversees variable using Secretariat-level clearance.