Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AllianceBioversityCIAT/alliance-research-indicators-client/llms.txt

Use this file to discover all available pages before exploring further.

Alliance Research Indicators is a role-aware application: what you can see and do is determined by the role or roles assigned to your account. The backend enforces all authorization decisions; the client mirrors those checks in the UI to hide actions you would not be permitted to perform, but the server always has final say. Role assignment happens at user provisioning by a system administrator — it is not self-service. The application recognizes three numeric role identifiers that drive access decisions in the RolesService and the route guards:
role_idRole nameGuard
1Admin (system-level)rolesGuard — authenticated access to all routes; passes all capability checks
9Center AdmincenterAdminGuard — requires role_id === 9 with matching focus_id === 1 and sec_role_id === 9, or role_id === 1
10MEL Regional ExpertrolesGuard — authenticated; isMelRegionalExpert computed signal is true
The canEditAnyResult computed signal is true for any user with role_id === 1, 9, or 10. Researchers and cross-platform consumers hold none of these roles and receive the base access set.

​
The four primary personas

​
Researcher / Result Reporter

The researcher is the primary creator of results. After authentication, a researcher can access all result-creation and editing flows for results they own. What a researcher can do:
  • Create a new result by selecting an indicator and filling the eleven metadata tabs
  • Save partial progress on any tab and return later without data loss
  • Attach evidence files (PDFs, images, datasets) via the file-manager service
  • Search results by text, indicator, year, country, partner, or project
  • Submit a completed result for MEL review
  • See the current lifecycle status (draft / submitted / under review / accepted / returned) of their results
  • Receive and address structured feedback when a result is returned from MEL review
What a researcher cannot do:
  • Edit results owned by other users (unless also holding a higher role)
  • Access the Center Admin bulk-upload or SDG management tools
  • Directly accept or publish results — that action belongs to MEL

​
Center Admin

The Center Admin role (role_id === 9) is for institutional administrators who need operational oversight and bulk capabilities for their center. Access to center-admin routes is gated by centerAdminGuard, which verifies that role_id === 9 with focus_id === 1 and sec_role_id === 9, or that the user holds the system Admin role (role_id === 1). What a Center Admin can do:
  • Everything a Researcher can do
  • Bulk-upload capacity sharing events for their center from a structured spreadsheet template, with per-row validation feedback
  • Manage SDG alignment settings at the center level so results roll up correctly in aggregate reporting
  • View all in-flight results owned by their center and identify bottlenecks in the lifecycle
What a Center Admin cannot do:
  • Access bulk-upload or SDG management for centers other than their own (scope is enforced via focus_id)
  • Accept or return results during MEL review — that action belongs to MEL Regional Experts
Center Admin access requires both the correct role_id (9) and the correct focus_id / sec_role_id combination on the role record. Having role_id === 9 alone is not sufficient. System Admins (role_id === 1) bypass this check and can access center-admin routes for any center.

​
MEL Regional Expert

The MEL Regional Expert role (role_id === 10) is for Monitoring, Evaluation & Learning specialists who are responsible for validating result quality and alignment within their regional scope. The canEditAnyResult computed signal in RolesService is true for users with this role. What a MEL Regional Expert can do:
  • Everything a Researcher can do
  • Edit any result in their scope, regardless of who created it
  • Leave structured review feedback on submitted results
  • Accept a submitted result (moving it to published state) or return it to the reporter with feedback
  • View aggregate dashboards filtered by region, indicator, and year
  • Export structured metadata for selected results to Excel for offline analysis
What a MEL Regional Expert cannot do:
  • Access the Center Admin bulk-upload or SDG management tools (those require role_id === 9 or role_id === 1)

​
Cross-Platform Consumer

Cross-platform consumers are authenticated users — funder analysts, leadership, partner researchers — who need to find and read results from across the federation. They hold neither a Center Admin nor a MEL Regional Expert role. What a cross-platform consumer can do:
  • Search results across the Alliance platform and federated results from STAR, TIP, PRMS, and AICCRA in a unified view
  • Follow deep links to individual results and view full metadata, evidence, partners, and cross-platform counterparts
  • Download OICR templates and reports
  • Access aggregate dashboards and charts
What a cross-platform consumer cannot do:
  • Create, edit, or submit results
  • Access center-admin tools
  • Accept or return results during review

​
Permissions matrix

The table below summarizes the key capabilities by role. “Yes (own)” means the action is permitted only on results the user created.
CapabilityResearcherCenter AdminMEL Regional ExpertCross-Platform Consumer
Create a resultYesYesYesNo
Edit own result (draft)YesYesYesNo
Edit any resultNoNoYesNo
Submit result for reviewYesYesYesNo
Accept / return result (MEL review)NoNoYesNo
Bulk-upload capacity sharingNoYesNoNo
Manage center SDG alignmentNoYesNoNo
View center-scoped result overviewNoYesNoNo
Search and view all resultsYesYesYesYes
Export results to ExcelNoNoYesNo
Download OICR templatesYesYesYesYes
Access aggregate dashboardsYesYesYesYes

​
Role enforcement in the client

Two Angular route guards implement role-based routing:
  • rolesGuard — the primary authenticated/unauthenticated gate. It checks cache.isLoggedIn() and the isLoggedIn flag on route data. Unauthenticated users attempting to reach a protected route are redirected to /login with a returnUrl query parameter so they land on their intended destination after authentication.
  • centerAdminGuard — a composite guard that calls roles.canAccessCenterAdmin(). This computed signal checks the full (role_id, focus_id, sec_role_id) tuple. If access is denied, the user is redirected to /home — not to login.
Beyond routing, the RolesService exposes computed signals (isAdmin, isMelRegionalExpert, canEditAnyResult, canAccessCenterAdmin, canEditOicr) that components use to show or hide individual UI elements such as edit buttons, submit actions, and admin-only menu items.
Client-side role checks are a UX convenience only — they hide actions that would be rejected. The backend enforces all authorization independently. Never rely on the client hiding an action as a security guarantee.

Authentication

How AWS Cognito and JWT-based authentication work, including token refresh and the login flow.

Center Admin guide

Walkthrough of bulk capacity sharing upload and SDG management for Center Admins.

Build docs developers (and LLMs) love

Get started for freeTalk to us