## User Story As any GitLab user, I want a personalized "Your Work" navigation panel that shows my assigned issues, merge requests, to-dos, and other work items across my organization so that I can quickly find and access my work without navigating through multiple projects. ## Problem Statement Most of the landing page "dashboards" within the Your Work sidebar are not yet scoped to Organizations: {width="155" height="329"} For each of these areas, we need to migrate them to support Organization context/scope, eg. so that when a user visits "Issues", the dashboard only shows them issues from their current Organization. An example of how we integrated Group creation within Organizations can be seen in this MR https://gitlab.com/gitlab-org/gitlab/-/merge_requests/200908. In some cases, the changes required to implement this behaviour are minimal and ~"group::organizations" can make them ourselves. For other scenarios, the changes require domain knowledge and context and ~"group::organizations" can only consult/support with scoping work. This Epic contains several child epics to deal with specific sections/verticals (eg, Security, Plan etc). This work typically involves: - Scoping the URL to Organizations - Filtering queries to be isolated by Organization ## Exit Criteria * Each of the areas in scope for [Protocells Cohort 1](https://gitlab.com/groups/gitlab-org/-/epics/18384) are updated to be scoped to the current Organization * Tests ensure that we have full confidence that data in these areas cannot cross Organization boundaries * The isolation requires is achieved at the framework level (eg. Rails) rather than alternatives (eg. RLS at the Postgres level) ## DRI @chen-gitlab @timmccarthy ## Guidance for other teams The integration of your feature with Organizations will happen like so: 1. User will request a path such as `/o/my-org/groups/new` - `/o` is the Organization path namespace - `my-org` is the Organization path attribute 2. :warning: You will need to extend Organization-scoped routes to include your routes 3. We will parse the `/o/my-org/*` path and set a `Current.organization` context for you. - This includes web, GraphQL, and REST requests. 4. :warning: You will pass the `Current.organization` from the controller layers through to finders/resolvers/etc to filter queries by the `Current.organization` You can learn more about the [Organization Path Scopes](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/004_path_scope/) and [Organization Context](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/001_organization_context_resolution/). Note that licensed features on GitLab.com are not currently available through dogfooding. You can enable Organizations on your GDK with the following feature flags: ``` Feature.enable :organization_switching Feature.enable :ui_for_organizations ``` ### Frontend guidance For questions reach out to @peterhegman 1. If you are using Vue router make sure `basePath` is set and is being passed from the backend. See https://docs.gitlab.com/development/fe_guide/vue/#vue-router for guidance. 2. Make sure there are no hardcoded internal REST API calls to controller endpoints. For example if you are making an API call to `/dashboard/activity.json` you need to pass the path to the frontend via data attributes similar to the guidance in https://docs.gitlab.com/development/fe_guide/vue/#vue-router <!-- STATUS NOTE START --> ## Status 2026-04-02 @chen-gitlab @timmccarthy @mandrewsgl Is this epic in-progress? If not, we can remove the ~"workflow::in dev" label so it stops asking for weekly status. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/19416#note_3215351741_ <!-- STATUS NOTE END -->