print page ④ of #8346: a record-page "generate PDF" action that calls the render service and attaches the archived PDF to the record #22270

Activity

1. objectstack-fleet

   added

   enhancementNew feature or requestNew feature or request

   priority:p2Medium: important, M3Medium: important, M3

   domain:spec

   target:v18

   pm:blocked

   on Oct 8, 2026
2. objectstack-fleet commented on Oct 8, 2026

   

   objectstack-fleetbot

   on Oct 8, 2026

   ContributorAuthor

   More actions

   Pointer from domain:services seat 1 (#6021) · session_01WkL6Eijt432S1Y7ekb6ovQ · 2026-10-08T12:00Z. ⛔ Not a claim. Nothing is owed back except a body amendment by this card's owner.

   #22269 (card ③) finished its design round. The seat's ruling OQ10 (6059301379, review on that card) answers who attaches the archived PDF to the record:

   • Card ③ attaches. Its service-storage in-process archive entry writes the pending sys_file, attaches it under the caller's own context (so the parent-read gate and the files gate fire), then commits, all in one unit.
   • Card ④ (this card) is the action, the door (route or action type), the button and the listing. It calls card ③'s service and relays its refusals (codes and statuses pinned at card ③'s service boundary: SERVICE_UNAVAILABLE / 503, VALIDATION_ERROR / 400, RESOURCE_NOT_FOUND / 404, RECORD_NOT_FOUND / 404, PERMISSION_DENIED / 403, and the registered FILES_DISABLED / 403).
   • This card's body line "It attaches the resulting sys_file to the record" should move to card ③. That is for the card's owner to amend.

   Card ③ is pm:blocked behind objectstack-ai/objectui#11958 (card ②), as this card is.
3. objectstack-fleet commented on Oct 15, 2026

   

   objectstack-fleetbot

   on Oct 15, 2026

   ContributorAuthor

   More actions

   Grade p2 → p1: the maintainer names PDF for 18.0 GA · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-15T23:16Z

   Source. The maintainer said 「PDF 要赶 18.0 正式版」 in this session's live chat on 2026-10-15, under the standing 「发版本优先的都p1」. The parent is #8346, and the same act moves it to p1.

   • Unchanged: pm:blocked on print page ③ of #8346: a render service with one headless-Chromium driver renders a print page under the requesting user's principal and archives the PDF as a sys_file (M2) #22269 (the body's line), target:v18, and the inherited domain:spec. Triage routes the card when it unblocks, and splits it across objectstack and objectui if the landing sites call for that.
   • Any split card takes p1.
   • Still owed by this card's owner: the body amendment that pointer 6059391513 asks for. Card ③ attaches the PDF; this card is the action, the door, the button and the listing.

   ⛔ Not a claim.
4. objectstack-fleet

   added

   priority:p1High: required for production / M2High: required for production / M2

   and removed

   priority:p2Medium: important, M3Medium: important, M3

   on Oct 15, 2026
5. objectstack-fleet commented on Oct 16, 2026

   

   objectstack-fleetbot

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Pointer from domain:services seat 2 (#21118) · os-elon-musk · session_018VqJPGA1NDNSCZsnecsChP · 2026-10-16T14:57Z · ⛔ not a claim. Nothing is owed back, except that this card's owner carries the two items below into the door's design, and amends the body as pointer 6059391513 already asks.

   Card ③'s service is at ACCEPT on PR #23811 (head 5a16f29db9). It lands on an authorized approval: it is over 3,000 lines. Once it merges, this card's Blocked-by: #22269 clears. Three things for the door:

   1. Two items from the mint review that bind at this door, not at card ③ (domain:spec seat 1's pointer 6206951646 on #22269, items 2 and 3). Card ③ has no door, so both were routed here by its contract records (6213039702 ③, 6214644798 ③).

   • Impersonation. ExecutionContext carries no impersonation marker. A print triggered while an admin impersonates a user mints a session for that user with impersonatedBy unset, and the mint's login audit row names the user alone. The reach is no wider than what the admin already holds, for at most the session's 60 s.
     • The door decides whether a print under impersonation mints at all, or how it is attributed.
     • A server-set marker on the context would be a packages/spec widening, which is the maintainer's decision.
   • Audit rows. Each print fires the existing session.create.after login writer when it mints, and the logout writer when it revokes, both with no endpoint path. The door decides whether a print is audited differently: a print row of its own, or the login/logout pair left as is.

   2. What the door relays, as card ③ answers at that head. This supersedes the list in 6059391513.

   • The service is the in-process print slot: IPrintService.printRecordToFile({ app, object, recordId, page, filename? }, context).
   • Hand it the request's own ExecutionContext, unchanged. The service passes that object to the mint by identity (pinned); the mint mints for whatever user the context names (6206951646 item 1).
   • Refusals, all before a session is minted or a browser started:
     • PERMISSION_DENIED / 403: not a human user acting for themselves;
     • SERVICE_UNAVAILABLE / 503: the engine is not ready, and status() says why;
     • RESOURCE_NOT_FOUND / 404: unknown page;
     • VALIDATION_ERROR / 400: a malformed request, or a page that is not the object's default record page or declares no print;
     • RECORD_NOT_FOUND / 404: the record does not exist, or the caller cannot read it;
     • FILES_DISABLED / 403;
     • PERMISSION_DENIED / 403: the caller may not create attachments;
     • ATTACHMENT_PARENT_ACCESS / 403: the caller may not edit the record, which attaching needs.
   • After them:
     • TIMEOUT / 504: the 30 s render budget;
     • INTERNAL_ERROR / 500: an engine failure, with secrets redacted;
     • the archive's own refusals, e.g. PAYLOAD_TOO_LARGE / 413 over the upload limit.
   • The PDF is attached by card ③, as the caller: sys_file.owner_id and sys_attachment.uploaded_by name them. The door does not attach a second time.

   3. Which page prints. Card ③ prints a record on its object's DEFAULT record page only, because the console renders a record there and nowhere else. A route that renders a named record page is filed in objectui (objectstack-ai/objectui#12715). Until it lands, a "generate PDF" action prints the default record page, which must declare print.

   ---

   Generated by Claude Code