You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a LinkedIn section to the organization detail screen, visible only to roles allowed to manage
it.
Tests: status parse; assignment round-trip; credential removal confirmation.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in the PR above (branch issue/42-org-linkedin). Closing here — review and any follow-up happens on the PR.
Three live findings contradict the help centre and are worth fixing in the docs:
GET …/linkedin/status returns {"credential":null,"role":"member"}, not the documented {"connected":true,"expiresAt":…}.
GET …/linkedin/assignments and GET …/linkedin/sync-pages answer 405 — the help centre's endpoint table lists GETs that do not exist. The status payload is the only source of pages and assignments.
PUT …/linkedin/assignments takes one {userId, pageId} pair, not a map of assignments. Omitting pageId clears that member (200 {"assigned":false}).
Good news on enforcement: unlike the member endpoints #83 found unenforced, the server does enforce roles here — a plain member gets 403 "Admin or owner required".
Still unconfirmed: the connected status payload, because no reachable account holds an organization LinkedIn credential. The DTOs are deliberately tolerant and sync re-reads status rather than trusting its own response shape, but this is worth re-probing the first time an org actually connects.
One throwaway org was created for the write probes and deleted; no real organization's credential or assignments were touched.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/42-org-linkedin). Closing here — review and any follow-up happens on the PR.Three live findings contradict the help centre and are worth fixing in the docs:
GET …/linkedin/statusreturns{"credential":null,"role":"member"}, not the documented{"connected":true,"expiresAt":…}.GET …/linkedin/assignmentsandGET …/linkedin/sync-pagesanswer 405 — the help centre's endpoint table lists GETs that do not exist. The status payload is the only source of pages and assignments.PUT …/linkedin/assignmentstakes one{userId, pageId}pair, not a map of assignments. OmittingpageIdclears that member (200 {"assigned":false}).Good news on enforcement: unlike the member endpoints #83 found unenforced, the server does enforce roles here — a plain member gets
403 "Admin or owner required".Still unconfirmed: the connected status payload, because no reachable account holds an organization LinkedIn credential. The DTOs are deliberately tolerant and sync re-reads status rather than trusting its own response shape, but this is worth re-probing the first time an org actually connects.
One throwaway org was created for the write probes and deleted; no real organization's credential or assignments were touched.
merge: #42 organization LinkedIn pages (PR)