[paynejd]

In TBv3 a pin is what an org or user highlights on its own overview page, and a follow is a personal shortcut listed in the left menu. This PR does the web part of the ticket; the data migration that turns TBv2 pins into follows is a separate oclapi2 PR.

What changed

• Repo page Actions menu: "Pin to <owner> overview" / "Unpin from <owner> overview", shown to people who can pin for the repo's owner: the owning user, the org's members, and staff. It also shows on a version page (where a repo page lands by default) and pins the repo itself, not the version. A short success message confirms the change, since the menu closes.
• Lists: the pin column is gone from search results (global search, and the org and user repository lists). PinActionButton was used only there, so it's deleted.
• Hover cards: the repo, org and user hover cards no longer have a Follow button. Follow stays on org pages, repo pages and user profiles.
• Limit: at 4 pins the error reads "You can pin up to 4 repositories. Remove a pin from the CIEL overview first." The same message shows when only the API knows the limit is reached. The overview's Pinned section keeps its remove buttons.
• Search bar browse lists: the Organization, Repository and User lists (type / in the search bar) drop their "Bookmarked" section, which read the signed-in user's own pins. They keep "My …" and "Following …", so personal shortcuts there are follows. Nothing else reads the cached user's pins, so the /user/ refresh no longer asks for includePins.
• The who-can-pin rule (canActOnPins) moves into a small pure module, src/common/pins.js, with unit tests. Its behaviour is unchanged.

No new UI component: the menu item reuses the existing Actions menu item pattern and PinIcon.

Verification

• Lint (CI's command) and npm test pass; 6 new tests in src/common/__tests__/pins.test.js.
• Ran the dev build against a read-only local proxy to the production API, with a fake signed-in non-staff user who is a member of CIEL. Pin writes were stubbed in the browser (POST 201 with a pin, DELETE 204, and a 404 {error} for the API-side limit). Results:
  • CIEL repo (latest released version, an older version, and HEAD): the menu shows "Unpin from CIEL overview". Unpinning sends DELETE /orgs/CIEL/pins/20/ and the item turns into "Pin to CIEL overview". Pinning then sends POST /orgs/CIEL/pins/ {"resource_type":"Source","resource_id":"42"} (the repo's id, also from a version page), and the item turns back.
  • Limit: with 4 pins in the list, pinning shows the limit message and sends nothing. With 3 pins and the API refusing, it shows the same message.
  • Another org's repo (WHO): no pin item, and no pins request. On a user-owned public repo, the owning user (faked) sees "Pin to <user> overview" and the CIEL member doesn't. Signed out: no pin item and no pins request.
  • The org repository list, the user repository list and global search (repos and orgs) have no pin icons.
  • The org, repo and user hover cards open with no Follow button. The org page, repo page and user profile still show Follow.
  • Search bar browse lists, with a fake user who follows an org, a repo and a user and has an org and a repo pinned: Organization shows "My Organizations" (CIEL) and "Following organizations" (WHO); Repository shows only "Following repositories" (ICD-10-WHO); User shows only "Following users". Neither pinned item appears.

Actions menu, pinned	Actions menu, after unpinning

Limit message:

Org repository list, no pin column:

Repo hover card, no Follow:

The screenshots/ocl_issues-2947 branch holds only these images and can be deleted after review.

Strings

New or changed keys under bookmarks in all four locales: pin_to_owner_overview, unpin_from_owner_overview, pinned_to_owner_overview, unpinned_from_owner_overview, and max_pins_reached (new text, now with {{max}} and {{owner}}). bookmarks.pin was used only by the removed list button, and search.bookmarked_organizations, search.bookmarked_repositories and search.bookmarked_users only by the removed browse sections, so they're deleted. The browse lists reuse the existing search.following_* titles.

pt-BR, for Filipe's review:

• pin_to_owner_overview: "Fixar na visão geral de {{owner}}"
• unpin_from_owner_overview: "Remover fixação da visão geral de {{owner}}"
• pinned_to_owner_overview: "Fixado na visão geral de {{owner}}"
• unpinned_from_owner_overview: "Fixação removida da visão geral de {{owner}}"
• max_pins_reached: "Você pode fixar até {{max}} repositórios. Remova primeiro uma fixação da visão geral de {{owner}}."

closes OpenConceptLab/ocl_issues#2947

🤖 Generated with Claude Code

https://claude.ai/code/session_01TjM9dGow2KV1Gwr2dWQdph

[paynejd]

Codex review, pass 1 (codex-cli 0.163.0, commit de4f258)

Verdict: clean. No findings.

findings.json

{
  "reviewer": "codex-cli 0.163.0",
  "perspective": "defects",
  "mode": "full",
  "commit": "de4f2581",
  "verdict": "clean",
  "prior": [],
  "findings": []
}

[paynejd]

Simplification review (fresh Claude subagent, commit de4f258)

Verdict: one proposed cut.

• S1 (shrink, RepoHeader.jsx L36): drop canPin from the pin prop, since usePins gets an owner only when canActOnPins is true. Declined: pins is state that usePins resets only in an effect, so in the render where the owner stops being pinnable the old list is still there; canPin is computed in that render and keeps the item hidden. It costs one line.

No code changed after Codex pass 1, so there is no follow-up Codex check.

simplify.json

{"reviewer":"claude subagent","perspective":"simplify","mode":"full","commit":"de4f258174e83fadb2a9913480e6cbfc7e01902f","verdict":"findings","prior":[],"findings":[{"id":"S1","severity":null,"tag":"shrink","file":"src/components/repos/RepoHeader.jsx","line":36,"claim":"The `canPin` check in the pin prop is redundant: usePins is only given an owner when canActOnPins(pinOwner) is true, so canPin is true whenever pins can be non-false (pins stays false when owner is false).","action":"Destructure `{ pins, findPin, togglePin }` and pass `pin={pins !== false ? {owner: pinOwner.id, pinned} : false}`.","lines_delta":-1,"confidence":"medium"}]}

[paynejd]

Codex check of commits de4f258..17c2c86 (codex-cli 0.163.0, commit 17c2c86)

Asked only whether 17c2c86 (search bar browse lists show follows; includePins and the search.bookmarked_* strings dropped) broke anything. Verdict: clean. No findings.

findings.json

{"reviewer":"codex-cli 0.163.0","perspective":"defects","mode":"cuts","commit":"17c2c864","verdict":"clean","prior":[],"findings":[]}

[paynejd]

Rebased onto main after oclweb3#72 merged (new head 867d75ea73ac7aebce1d7c45782ae22764fc1894). The one conflict was in src/components/orgs/OrgHome.jsx, where #72 had added defaultFiltersOpen and onFiltersOpenChange next to the pins/canPin/onPinToggle props this PR removes. The resolution keeps #72's two filter props and drops the pin props. git range-diff shows no other change to either commit. Lint (CI's command) is clean and npm test passes 26/26.