Skip to content

Notifications - #2021

Open
david-rocca wants to merge 38 commits into
2.9.0-releasefrom
dr_notifications
Open

david-rocca wants to merge 38 commits into
2.9.0-releasefrom
dr_notifications

Conversation

@david-rocca

Copy link
Copy Markdown
Collaborator

No description provided.

jdaigneau5 and others added 30 commits August 13, 2026 12:59
Merging 2.8.4 from staging to prod
merge 2.8.5 from dev to test
Bumps [morgan](https://github.com/expressjs/morgan) from 1.11.0 to 1.12.0.
- [Release notes](https://github.com/expressjs/morgan/releases)
- [Changelog](https://github.com/expressjs/morgan/blob/master/HISTORY.md)
- [Commits](expressjs/morgan@1.11.0...1.12.0)

---
updated-dependencies:
- dependency-name: morgan
  dependency-version: 1.12.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
…an-1.12.0

Bump morgan from 1.11.0 to 1.12.0
Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 3.15.1 to 3.15.2.
- [Changelog](https://github.com/nodeca/js-yaml/blob/3.15.2/CHANGELOG.md)
- [Commits](nodeca/js-yaml@3.15.1...3.15.2)

---
updated-dependencies:
- dependency-name: js-yaml
  dependency-version: 3.15.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
…aml-3.15.2

Bump js-yaml from 3.15.1 to 3.15.2
  requested organization
- derive top_level_root from the current organization, its parent, or
  its grandparent when is_top_level_root is enabled
- return minimal related organization metadata containing UUID,
  short_name, and long_name
- keep related organizations within single-organization responses
- collect and deduplicate related organizations at the top level of
  paginated organization responses
- preserve the existing legacy organization response path
- omit reports_to and top_level_root when no corresponding relationship
  can be resolved
- add BaseOrg UUID and oversees indexes for hierarchy lookups
- add an idempotent migration for existing database deployments
- document the UUID-based top_level_root and related organization
  response fields
- cover direct and two-level ROOT reporting relationships
- add unit coverage for paginated related organization deduplication
Add a Secretariat-only GET /api/registry/org-hierarchy endpoint that
returns the complete, unpaginated organization forest. Project each node
to short_name, long_name, and children.

Build hierarchy responses from one lightweight organization query.
Construct parent and child maps in JavaScript so traversal remains
linear, supports arbitrary depth, and avoids repeated database reads.
Handle standalone organizations, missing references, duplicate edges,
multiple parents, self-references, and cycles defensively.

Add _hierarchy to GET /api/registry/org/:identifier. Return the path from
the top-level Root to the requested organization while excluding sibling
branches from its ancestors. Include the requested organization's
complete descendant subtree.

Remove _relatedOrganizations from registry organization list and detail
responses, along with the additional aggregation lookup used to hydrate
it. Continue using _userMap for expanded user and conversation-author
metadata.

Add recursive JSON schemas and OpenAPI documentation for the hierarchy
endpoint and embedded _hierarchy response. Expose the standalone
hierarchy response schema through the schemas controller.

Expand development population data to exactly 1,000 organizations. Add
two top-level Roots with four child Roots each, assign four CNAs directly
to each top-level Root, and distribute the remaining CNA organizations
across the child Roots. Keep the Secretariat and sister_20 organizations
standalone.

Add unit and integration coverage for hierarchy projection, trimming,
access control, schema validation, deep traversal, malformed
relationships, organization renames, subtree moves, and populated seed
distribution.

BREAKING CHANGE: Registry organization responses no longer include
_relatedOrganizations. Single-organization responses now expose
_hierarchy, and the paginated organization list contains neither field.
Expose each organization's UUID alongside its short name, long name, and
children in full and trimmed hierarchy responses. This allows hierarchy
nodes to be correlated with reports_to, top_level_root, and oversees
references.

Update the recursive response schemas and OpenAPI documentation to
require UUIDs. Configure hierarchy schema tests with ajv-formats so UUID
validation is recognized.

Correct populated hierarchy expectations for four child Roots per
top-level Root, and update organization-list integration tests to locate
records across paginated responses.
Update test to 2.8.6 - RC1
This reverts commit d478941.
Comment thread src/controller/notification.controller/index.js Dismissed
Comment thread src/controller/notification.controller/index.js Dismissed
Comment thread src/controller/notification.controller/index.js Dismissed

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants