> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0022-activity-view-modes-single-parameter.md).

# ADR-0022: Activity view-modes are a single enum parameter

## Status

**Accepted.** Reconstructed from the codebase on 2026-05-30; the decision is live in the source today.

## Context

The activity feed offers several views of the same stream: everything, only the caller's own objects, and the upstream/downstream lineage neighbourhood of the caller's objects. There are two ways to expose those views over HTTP: one endpoint per view (`/api/activity/mine`, `/api/activity/upstream`, …), or a single endpoint with a parameter that selects the view. The platform had to pick one shape for the activity feed.

## Decision

**The activity feed exposes its view-modes as a single `ActivityType` enum parameter on `GET /api/activity`, dispatched server-side — not as separate endpoints.** The enum has four members (`ALL`, `MY_OBJECTS`, `DOWNSTREAM`, `UPSTREAM`); the service layer switches on the value to the matching query (`fetchAllActivities`, `fetchMyActivities`, `fetchDependentActivities` for the two lineage directions). An unset `type` falls through to the `ALL` behaviour.

This is a **deliberate divergence** from the owner-scoped reads on `DataEntityController`, which expose the structurally similar "my / my-upstream / my-downstream" views as *separate* endpoints (`/my`, `/my/upstream`, `/my/downstream`). The same platform uses parameter-dispatch for the activity feed and separate-endpoints for data-entity listings — the activity feed's view dimension is a query parameter; the data-entity feed's is a path.

## Consequences

* Adding a new activity view-mode is an enum addition plus a switch arm — one endpoint stays the single entry point; no new routes, no new generated interface methods.
* The view dimension is a parameter callers must know about rather than a discoverable URL, and the four modes are not currently spelled out on the activity-feed feature page — the affordance is in the API contract, not the prose.
* The platform carries two shapes for "scope this feed to me / my lineage": enum-parameter (activity) and separate-endpoints (data-entity owner reads). A contributor extending either should follow the local shape, not assume one global convention — the divergence is real and intentional, not an oversight.
* `type` unset and `type=ALL` both route to the all-activities query through distinct branches; they are equivalent today, which is worth knowing for anyone later adding scoping to one of those paths.

## Evidence

* `odd-platform-api/.../controller/ActivityController.java:32` — `getActivity(... final ActivityType type, ...)`: the view-mode is one enum parameter on the single endpoint.
* `odd-platform-api/.../service/activity/ActivityServiceImpl.java:103-117` — the dispatch: `if (type == null) return fetchAllActivities(...);` then `switch (type) { case MY_OBJECTS -> fetchMyActivities(...); case DOWNSTREAM -> fetchDependentActivities(..., DOWNSTREAM); case UPSTREAM -> fetchDependentActivities(..., UPSTREAM); case ALL -> fetchAllActivities(...); }`.
* The generated `ActivityType` enum (`api.contract.model.ActivityType`) carries exactly the four members `ALL` / `MY_OBJECTS` / `DOWNSTREAM` / `UPSTREAM`, imported at `ActivityController.java:10`.

## See also

* [Activity Feed](/features/active-platform-features/activity-feed.md) — the feature whose views this parameter selects.
* [ADR-0021 — Activity streams use cursor pagination](/developer-guides/architecture-decision-log/adr-0021-activity-stream-cursor-pagination.md) — the companion pagination decision for the same endpoint.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opendatadiscovery.org/developer-guides/architecture-decision-log/adr-0022-activity-view-modes-single-parameter.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.