Puranjay Savar Mattas
ad3e35e28e
Same root-cause fix as feature/home-page, applied to this branch's
copy of the pin code (which additionally has the sidebar's real
per-collection Pin wiring):
- pins.list's real response is {data: {pins: [...], documents: [...]}},
not a bare array — confirmed against a live server. Decoding straight
to [OutlinePin] threw every call; try? swallowed it, so pins never
showed up (even a doc pinned for real via the web app).
- "Pin to Home" (web's actual label) sends collectionId: null; "Pin to
Collection" sends a real id — distinct actions. The reader toolbar's
Pin was sending the doc's own collectionId under a plain "Pin" label,
silently doing the wrong one. Fixed to nil, relabeled "Pin to Home".
- Sidebar's per-document Pin was already correctly scoped to
collection.id — relabeled "Pin to Collection" for clarity, no logic
change.
15 lines
617 B
Swift
15 lines
617 B
Swift
import Foundation
|
|
|
|
/// A document pinned to the top of a collection, or to team Home when
|
|
/// `collectionId` is `nil`. Backed by `pins.*` — not in the vendored OpenAPI
|
|
/// spec (`docs/reference/outline-openapi`, no `Pins` tag at all), but
|
|
/// confirmed real against a live server's network traffic. `collectionId: nil`
|
|
/// is what "Pin to Home" actually sends; a non-nil value is "Pin to
|
|
/// Collection", a distinct action.
|
|
public struct OutlinePin: Decodable, Identifiable, Sendable {
|
|
public let id: String
|
|
public let documentId: String
|
|
public let collectionId: String?
|
|
public let index: String?
|
|
}
|