Caleb Updates - #62
Merged
Merged
Conversation
…ement in UI text TK-68: Update button labels, signed labels, tooltips, and the related validation message so they refer to "Information Sharing Agreement" instead of "Confidentiality Acknowledgement", matching the correct agreement name. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…me-in-sharing-agreement TK-68: Change of Button name in Sharing Agreement
…e Items, Groups, and the Administration Dashboard. Why? Several admin-role restrictions from the TK-24 acceptance criteria were encoded in test expectations but not implemented — External Users could still create ISAs and Knowledge Items, view groups they weren't a member of, and read Categories/Retentions/External Organizations from the Administration Dashboard. What? - ArchiveItemsPolicy#create and InformationSharingAgreementPolicy#create now block External Users from creating ISAs and Knowledge Items. - ArchiveItemsPolicy#show now lets System Admins view Knowledge Items outside their ISA Group, resolving a contradiction in the ticket in favor of its "System Admins" section over its "Internal YG employees" section. - GroupPolicy#show and .policyScope now restrict External Users to groups they belong to. - CategoryPolicy, RetentionPolicy, and ExternalOrganizationPolicy now block External Users entirely, since Administration Dashboard access is limited to Users and Groups for them. - Adds policy test coverage for Group, UserGroup, ArchiveItems, Category, Retention, and ExternalOrganization to lock this matrix in. See TK-24.
…y-matrix---admins TK-24: User access Security Matrix - Admins
…er-doesnt-show-fn-name TK-87: Editing External user doesn't show FN name
Why? UpdateService already refused to let an Admin or External Admin grant the system admin role, but CreateService never checked, so an Admin could hand a brand-new user system admin just by including it in the create request. What? CreateService now runs the same canGrantRole check as UpdateService before dispatching to CreateInternalService/CreateExternalService. Also adds controller-level test coverage for the full TK-36 create authorization matrix (System Admin/Admin/External Admin/User, against internal and external targets), and service-level coverage for UpdateService's existing role-escalation guard, which had no direct test. See https://yg-hpw.atlassian.net/browse/TK-36 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…user-creation TK-36: Lock down external user creation
…ntact labels. Replaces the "Transboundary" contact terminology with the approved "Yukon First Nation or Indigenous Government" wording on the information sharing agreement contact name and title fields. See https://yg-hpw.atlassian.net/browse/TK-61
Adds blank lines around headings/lists, pads table separator rows, and wraps bare URLs per markdownlint rules. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…-creating-an-agreement TK-61: Label Change - When creating an agreement
TK-65: ISA changes
Applies the Shannon-approved TK-76 login copy: removes the Yukon Government subtitle, renames the MyYukon credentials line, swaps the Secure Digital Storage note for the TK Vault access statement, and replaces the library logo with the green Information Sharing Agreement disclaimer. Renames the application to Traditional Knowledge Vault so the browser tab reads Traditional Knowledge Vault - Sign In. See https://yg-hpw.atlassian.net/browse/TK-75
Vuetify uppercases v-btn labels by default; text-none keeps it as Sign in per the approved TK-76 copy. See https://yg-hpw.atlassian.net/browse/TK-75
…ges-for-the-login-page TK-75: Disclaimer text and changes for the login page
Renames the browser tab to "Traditional Knowledge Vault : Sign In" and removes the Yukon sunburst favicon so no government logo appears in the tab. See https://yg-hpw.atlassian.net/browse/TK-77
…site TK-77: Traditional Knowledge Vault branding in the website tab
The ISA Manager (secondary contact) field now searches the Yukon Government directory instead of existing app users, so any employee can be named on the contract. The client submits the selected email; the controller resolves it to an internal user (creating one from the directory when missing) and stores its id. Group creation already excludes this contact, so the Manager never gains group admin or membership. See TK-66. See https://yg-hpw.atlassian.net/browse/TK-66
Why? The internalGroupSecondaryContactEmail write-side field spread directory resolution across the ISA controller, policy, and serializer for a value that is not a real column. The ISA endpoints accept internalGroupSecondaryContactId again. The client resolves the selected directory email to an internal user through the new POST /api/users/directory-users endpoint before saving, and prefills the edit form by looking the contact up by id. External users cannot reach the new endpoint, matching who may author an agreement. See https://yg-hpw.atlassian.net/browse/TK-66
…ectory-when-searching-for-manager-while-creating-an-isa TK-66: Search the Active Directory for the ISA Manager Contact
Why? The Matomo integration was already present but never recorded: the production build shipped with an empty tracker host, and the app's Content Security Policy blocked the external tracker script and beacons. Default the production tracker host to https://analytics.gov.yk.ca (still overridable via VITE_MATOMO_HOST) and allowlist it in the script-src and connect-src CSP directives. Non-production environments stay disabled. See https://yg-hpw.atlassian.net/browse/TK-34
…cs-code-integrated-for-website-analytics TK-34: Record Matomo Analytics in Production
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces several improvements and new features to the backend API, focusing on authorization, user management, and security configuration. The most significant changes include the addition of a new controller for resolving directory users, stricter access controls for external users in key policies, and enhancements to the Content Security Policy (CSP) to support Matomo analytics tracking. There are also workflow documentation updates and minor code cleanups.
API Features and Access Control
DirectoryUsersControllerfor securely resolving directory users by email, restricted to internal users only. [1] [2]ArchiveItemsPolicyandCategoryPolicyto deny access for external users in both resource access and policy scope, improving security and data segregation. [1] [2] [3]Security and Configuration
MATOMO_TRACKER_HOSTto the configuration and CSP headers, allowing scripts and connections to the Matomo analytics host. [1] [2] [3]Documentation and Workflow Improvements
Code Quality and Maintenance