Skip to content

fix(trustlab): handle internal and external org links dynamically via CMS#1492

Merged
kilemensi merged 8 commits into
mainfrom
fix-opportunity-organisation
Jun 22, 2026
Merged

fix(trustlab): handle internal and external org links dynamically via CMS#1492
kilemensi merged 8 commits into
mainfrom
fix-opportunity-organisation

Conversation

@kilemensi

@kilemensi kilemensi commented Jun 22, 2026

Copy link
Copy Markdown
Member

Description

Summary

Org links in ParticipatingOrganizationList were previously hardcoded: card-variant links were auto-derived by walking the CMS page tree, while chip-variant links used whatever was stored in link.href — with no way for editors to control either. External and internal links were treated identically, and all chips opened in a new tab unconditionally.

This fix moves link configuration onto each Organisation document: an includeLink toggle lets editors opt out entirely, and the linkGroup lets them pick between a custom external URL or an internal page link. The blockify layer resolves the correct href based on linkType, and target="_blank" is dropped since internal links should navigate in-place.

Changes

  • Organisations collection — add includeLink checkbox and update linkGroup config (disableLabel, disableOpenInNewTab, required: false); make slug required; fix Organisation/Organization label typos
  • ParticipatingOrganizationList block — fix label typos; make the organisations relationship field sortable
  • getParticipatingOrganizationListBlock — replace hardcoded page-tree path derivation with per-org includeLink/linkType/ link.href resolution
  • pagifyOpportunities — remove redundant blockify call (blockify already runs after pagify in the common pipeline)
  • ChipList — remove hardcoded target="_blank"; link behaviour is now driven by CMS config

Notes for reviewers

  • Existing org documents will have includeLink read as true (Payload applies defaultValue at read time for fields absent in stored docs), so no data migration is needed.
  • For internal links, link.href is stored at org-save time via a beforeValidate hook. If the linked page is ever renamed, affected org documents need to be re-saved to refresh their stored href.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Screenshots

N/A

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation

…sations

- Add `includeLink` checkbox (default true) to control whether an org
  displays a link; conditionally show the link group in admin UI
- Update linkGroup to disable label and open-in-new-tab fields, keeping
  link config minimal
- Fix Organisation/Organization label typos in both the collection and
  the ParticipatingOrganizationList block
- Add isSortable and sortOptions to the organisations relationship field
- Regenerate importMap (quote style only)
…d of page tree

Replace the page-tree path derivation (api.findPage + fullSlugFromParents)
with per-org includeLink/linkType/link.href fields set directly in the CMS.
Custom links use link.href as-is; internal links append org.slug to the
stored parent-page href.
blockify is already called after pagify in the common pipeline, so calling
it inside pagifyOpportunities was double-processing every block. Remove the
inner call; inject date/location into overview blocks directly before
returning to the pipeline.
Link behaviour (same-tab vs new-tab) is now controlled at the org level
via the CMS linkGroup config (disableOpenInNewTab). Rename ExternalLinkIcon
import to LinkIcon to reflect that it appears on any linked chip, not only
external ones.
@kilemensi kilemensi self-assigned this Jun 22, 2026
@kilemensi kilemensi added bug Something isn't working enhancement New feature or request labels Jun 22, 2026
@github-project-automation github-project-automation Bot moved this to 🚧 In Progress in COMMONS Jun 22, 2026
chatgpt-codex-connector[bot]

This comment was marked as resolved.

chatgpt-codex-connector[bot]

This comment was marked as resolved.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ae28aaf7cd

ℹ️ 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".

@kilemensi

This comment was marked as resolved.

@claude

This comment was marked as resolved.

@kilemensi

This comment was marked as resolved.

@claude

This comment was marked as resolved.

@kilemensi kilemensi requested review from a team and kelvinkipruto June 22, 2026 12:18
@kilemensi kilemensi added this pull request to the merge queue Jun 22, 2026
Merged via the queue into main with commit fa20209 Jun 22, 2026
14 checks passed
@kilemensi kilemensi deleted the fix-opportunity-organisation branch June 22, 2026 13:06
@github-project-automation github-project-automation Bot moved this from 🚧 In Progress to ✅ Done in COMMONS Jun 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working enhancement New feature or request

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

2 participants