2 Commits

Include renames

Author	SHA1	Message	Date
3 people	b795b219a8	✨ PUT-1497: Share file link sharing and notifications (#3595) ... * refactor(share): move share notifications into their own service * feat(share): invite an address with no account, and email it * feat(share): surface pending invites in the SDK and share dialog * fix(share): unreachable revoke confirmation, and double-encoded labels * feat(share): budget share announcements, group them, and let people block senders Sharing had one defence against noise: a 15-minute quiet window per (sender, recipient) pair, which dropped the second share rather than folding it in. Twenty senders each under their own window could still bury someone, and there was no way to make one of them stop. Announcements are now budgeted on two axes through the existing sliding-window limiter: 1 per 15 minutes and 20 per day from one sender, and 10 per hour / 50 per day to one recipient from anyone. Over budget the share still succeeds and the recipient's notification is still brought up to date — only the interruption is dropped. Invite email to an address with no account is budgeted the same way, keyed on a hash of the canonical address. Notifications now fold across senders: a new share rewrites the notification the recipient hasn't dismissed, so "alice and bob shared 5 items with you" replaces a stack of five. The record is written even when suppressed, so the count is right whenever they next look. Blocking is a new `user_block` table with enforcement in ShareService: a blocked sender's share is refused with `recipient_not_accepting_shares`, spends no quota, and writes no row, and their unclaimed invite is dropped when the address is confirmed. Existing access is untouched — that is what revoke is for. Managed from a Blocked people card in the dashboard's Security tab. Also publishes the sharing limits, including the ones already on this branch that were never documented. * fix(share): name the item in share email, instead of 'an item' * fix(share): make the invite lifecycle canonical, authorized, and race-safe * refactor(email): drop EmailClient.isConfigured; callers read config.email * feat(share): batch share email into a per-recipient digest, durably * docs(share): document the share error codes; steady the disk migration tests * fix(share): log why a digest wasn't sent, and recover orphaned ones * feat(share): email recipients about shares by default, with a way to decline Share email was off unless a deployment opted in, which meant an account holder was told about a share in the app only. It is now on unless `share_email_notifications` is set to false. The reason it defaulted off was that nobody could decline. So this also honors `user.unsubscribed` — the account-wide opt-out the /unsubscribe page already writes and app feedback already respects, which share email ignored — and the digest carries that link. Sharing and the in-app notification are unaffected by it; only the mail stops. The link is composed in the template around an interpolated uuid rather than passed pre-built: Handlebars escapes interpolated values, so a whole URL came out as `user_uuid&#x3D;…`, which browsers decode but link scanners and older mail clients need not. * fix(share): count every shared file in the digest, not just the first * feat(share): let a recipient refuse shares from everyone Blocking answered "not from this person" but had no answer to "not from anyone", so the only way to stop a stream of unwanted shares was to name each sender after they had already reached you. Stored as a key in the user row's existing `metadata` blob rather than a column: the share path already holds the recipient's row by the time it asks, so reading it costs nothing, and a one-bit preference doesn't earn a migration per dialect. `updateMetadata` merges and refreshes the cached row, so the switch bites on the very next share. Refusing everyone reports the same code as refusing one person — which of the two it is is the recipient's business, not the sender's. Enforced at both moments the per-sender block is: when the share is issued, and when a pending invite is claimed. The per-sender list is untouched while the blanket switch is on, so turning it off restores what it hid. `GET /share/blocks` now carries `all`; `POST`/`DELETE` take `{ all: true }` beside the existing `{ username }`. Managed from the same Blocked people card in the dashboard's Security tab. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(share): keep the digest sweep off a window that still has a timer The sweep treated an entry as orphaned the moment its window closed, which is also the moment the node that armed it fires. Claiming an entry is only exclusive among flushers that can see each other's deletes, so the two could each claim a share of the same digest and both send. It now waits out a grace period first, which costs a genuinely stranded digest that much delay and nothing else. Both digest listings were capped at 200 with no word when they hit it — a truncated flush sends a digest that undercounts and reads as complete. The cap is named and logged. Also: `#emailHolder` still described share email as off by default, which it stopped being; the config doc said the batch window defaults to 60s when it is 90; and the two tests that need several calls inside one window were racing a 50ms window across four sequential round trips, so they failed under full-suite load rather than on the behaviour they cover. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(share): stop double-encoding the recipient in two dialog messages `i18n()` encodes what it returns, replacements included, so encoding the recipient first showed the entities to anyone whose address or username contains one. Same pattern already fixed two lines above. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(notification): widen the mysql shown/acknowledged columns Both arrived from the v1 schema as `tinyint(1)`, where they were flags. The backend rework changed the writes to a unix second; sqlite (`INTEGER`) and postgres (`bigint`) took it and mysql did not, so on mysql every `markShown` and `markAcknowledged` has failed with ER_WARN_DATA_OUT_OF_RANGE and left the column NULL. Dismissing a notification never stuck — the unacknowledged count never moved and one already delivered came back on every reconnect. No backfill: every reader tests `IS NULL` / `IS NOT NULL` only, so a legacy `1` keeps meaning "yes" once widened. Guarded on the current type, because changing a column type copies the table and this directory replays on every boot. Not reachable from the test suite — it runs against sqlite and postgres, both of which already have the right type. Verified by hand against mysql: `/notif/mark-read` and `/notif/mark-ack` now persist, and a dismissed share notification is no longer the one a later share folds into. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Daniel Salazar <daniel.salazar@puter.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 09:36:33 -07:00
Nariman Jelveh	7ceb2090b7	feat: app user feedback system (#3546) ... * feat: app user feedback system Add puter.ui.showFeedbackDialog(), letting users send feedback to an app's developer. In the app environment the Puter desktop renders the dialog; on a third-party website a puter.com popup hosts it. The message is stored in a new app_feedback table and emailed to the app owner's confirmed email — it never passes through the app's own code. Feedback is strictly opt-in per app via a new apps.feedback_enabled column (a real column, not an app-metadata key, so Dev Center's whole-blob metadata saves can't silently erase it), settable through the existing puter.apps.update path (feedbackEnabled). Backend follows the layered stack: AppFeedbackStore (durable count queries) -> AppFeedbackService (opt-in check, message normalization, abuse caps, best-effort owner email) -> AppFeedbackController (POST /app-feedback, GET /app-feedback/target). New app-user-feedback email template uses the escaping-safe nl2br triple-stash. Defensive by design: - requireUserActor blocks app tokens, so feedback can't be submitted programmatically; guiOriginOnly keeps cross-origin pages out. - App identity comes only from the validated IPC sender (desktop) or the browser-attested opener origin (popup), never from message contents. - The send-feedback popup action is in NON_AUTH_POPUP_ACTIONS, so it never delivers a token to the opener. - Layered limits: route rate limits, plus DB-count caps that fail closed when the limiter backend is down, plus a per-app daily owner-email cap. - Owner email is fully best-effort: an unconfigured transport, unconfirmed/unsubscribed/suspended owner, or send failure never fails the request or blocks storage. - The dialog and SDK method are resolve-only and always settle, so a caller is never left hanging. Migrations for sqlite/mysql/postgres, puter.js types, docs, backend tests (sqlite + postgres), and a Playwright e2e spec are included. * feat: add feedback control to the dashboard app-drawer Surface the feedback dialog directly from the app window's chrome in dashboard mode: apps that opt in (apps.feedbackEnabled) get a "Send Feedback" button in the dashboard app-drawer, next to minimize/close. It opens the same UIWindowAppFeedback dialog, targeting this app by uid. The control is only rendered when the app opted in — feedback_enabled is threaded from the launched app's metadata into the window options — and the dialog still re-checks opt-in server-side, so a stale flag can't send anywhere. Reuses the existing .dashboard-app-drawer-btn styling and the app_feedback_title i18n string, so no new CSS or strings. Adds e2e coverage: the control appears and opens the dialog for an opted-in app, and is absent for an app that hasn't opted in. * feat: enable app feedback by default in Dev Center New apps created in Dev Center now have feedbackEnabled set on creation, so users can send the developer feedback without any extra setup. A "User Feedback" toggle in the app's settings lets developers turn it off (and back on); it's wired into the save payload, the dirty-state tracking, and the reset-to-original path like the neighboring toggles. The Save update omits feedbackEnabled unless the toggle is present, and the backend leaves an omitted field untouched, so the default survives the create-then-save flow Dev Center runs. Add an SDK apps-suite guard covering that round-trip (create-on -> unrelated update keeps it -> can be turned off). * fix: feedback modal polish + share sender email Address four issues with the app feedback UI: - Dashboard app-drawer: the extra "feedback" control pushed the close button past the drawer's derived width and clipped it. A `has-feedback` modifier widens the surface by one button + gap so all three controls fit. The control's glyph is now a message bubble with text lines, which reads more clearly at 14px than the previous bare speech bubble. - The feedback dialog is no longer a UIWindow. It's a from-scratch overlay modal in the spirit of the dashboard modals (uninstall, add-app): a fixed scrim + centered card with self-contained, theme-aware color tokens (light default + dark override), a bottom-sheet layout on narrow screens, backdrop/Escape close, and an entrance transition. This renders consistently across the three contexts it's opened from (desktop app-IPC, dashboard drawer, standalone popup), so the callers no longer pass UIWindow-specific window_options. - Feedback now shares the sender's email (not just their username) with the developer so they can respond: the owner email sets Reply-To to the sender and shows the address in the body — but only when the sender's email is verified (an unverified address could be anyone's, so it's never used as a reply target). EmailClient.send gains an optional replyTo. The dialog note now says the email will be shared. Tests: e2e updated for the new modal (7 pass); backend feedback suite covers the verified/unverified sender-email split (sqlite + postgres); EmailClient + GUI unit suites pass; type-check clean. * fix: resolve 'app-'-prefixed app names in feedback target lookup APP_NAME_REGEX allows names beginning with "app-" (e.g. the seeded app-center), but resolveTargetApp's startsWith('app-') heuristic sent those to a uid-only lookup with no name fallback, so feedback for such apps 403'd even when enabled. Use AppStore.resolveApp (uid, then name) like the rest of the codebase. * fix: make feedback daily caps fail closed under concurrent submissions The per-user and per-user-per-app caps were check-then-insert and the per-app email cap was count-then-send, so parallel requests (or multiple nodes, or the route limiter failing open) could all read a stale under-cap count and push past every limit — the exact scenario the DB-backed caps exist to stop. Now the user caps recount after the insert (own row included) and roll the row back with 429 if a burst breached them, and the email cap claims its slot (email_sent=1) before sending, recounts, and releases the slot if over cap or if the send fails. * docs: disclose the Dev Center's feedback-on-by-default in SDK docs/types The Dev Center deliberately creates apps with feedbackEnabled (see 32c950de5), but the SDK docs, apps.d.ts, and AppFeedbackService's class doc all described feedback as strictly opt-in / default-false with no qualification — so a Dev Center developer reading them would wrongly conclude feedback is off for their app. State the Dev Center behavior alongside the API default, and correct the update-path docs: an omitted feedbackEnabled leaves the current value unchanged rather than defaulting to false. * fix: don't mint a user-app token as a side effect of the feedback popup Every embedded_in_popup boot ran the user-app token exchange, and the exchange is a write: /auth/get-user-app-token bootstraps an app row for the opener origin, grants flag:app-is-authenticated (what makes the site count as connected to the account), and creates its AppData dir. So merely opening — or immediately cancelling — a send-feedback popup recorded a user<->site relationship the read-only feedback flow never needs: the server resolves the feedback target from the attested origin without any of it. Gate the exchange behind runsUserAppTokenExchange(action) in all three popup paths that mint (main postAuthActions exchange, temp-user signup success, manual signup fallback). request-permission keeps the exchange since grants are written against the app row it bootstraps. * fix: refuse feedback when the deployment cannot deliver it With no email transport configured (the common self-hosted default), submissions were stored in app_feedback — a table with no read path beyond the abuse-cap COUNTs — the owner email was silently skipped, and the sender was still shown 'Feedback sent. Thank you!'. The developer never learns the feedback exists while the user believes it was delivered. Gate acceptsFeedback on clients.email.isConfigured so the pre-flight reports enabled:false (the dialog shows its 'not accepting feedback' pane) and submit returns 403 instead of swallowing messages. Owner-level store-without-email cases (unconfirmed owner email, per-app email cap overflow) keep their existing deliberate semantics. * fix: settle showFeedbackDialog instead of hanging on older host GUIs In the app environment showFeedbackDialog awaited an IPC reply with no capability check. A host GUI that predates this feature (self-hosted Puter running the live js.puter.com SDK) has no handler for the message and never replies, so the promise documented as 'never rejects' also never resolved. The GUI now advertises the IPC dialogs it can answer via a puter.gui_features param on the app iframe URL, and the SDK resolves false when 'feedback-dialog' isn't listed. A reply timeout could not substitute: legitimate replies only arrive when the user closes the dialog, so any timeout would false-negative while the user is typing. Older SDKs ignore the extra param. * fix: guard app-triggered feedback dialog against desktop-lockout loops The showFeedbackDialog IPC handler had no re-entry or abuse guard, and the dialog it opens is a full-viewport overlay above the taskbar and every window — so 'while (true) await puter.ui.showFeedbackDialog()' kept the desktop permanently covered (for signed-out users, the same loop spams the full-page signup window instead). Every dismissal just settled the promise and let the app immediately reopen it. Allow one dialog at a time, and back off reopens per app after each dismissal that sent nothing: 10s, then 60s, then blocked until page reload. A successful send resets the backoff, and user-initiated paths (dashboard drawer) are unaffected since they don't go through IPC. * fix: carry feedback_enabled in suggested/recommended app summaries launch_app uses options.app_obj verbatim when provided, and the suggested-apps launch paths (open_item.js, UIWindowSearch.js, UIDesktop.js) pass summaries from toAppSummary — which omitted feedback_enabled. So an opted-in editor launched by opening a .txt file showed no Send Feedback control in the dashboard drawer, while the same app launched from the Apps tab (full puter.apps.get object) did. * fix: gate feedback dialog Cancel/X on an in-flight submit Escape and backdrop clicks were already ignored while the POST was pending, but the X, Close, and Cancel buttons weren't — clicking one mid-send settled the promise false and tore down the overlay while the submission still landed server-side: the developer got the email, the app was told sent=false, and a user who resubmitted 'the failed one' sent a duplicate and burned a daily-cap slot. Apply the same !sending gate to the buttons and disable them visually while the send is in flight. * fix: reject feedback origins longer than the source_origin column readTargetParam accepted values up to 3000 chars but the raw origin is stored verbatim into source_origin VARCHAR(2048) (MySQL/Postgres), so a 2049-3000 char origin passed every validation and then blew up the INSERT with an HTTP 500 on Postgres/strict MySQL — or was silently truncated on non-strict MySQL, corrupting the abuse-forensics value the column exists for. Cap the param at the column size. * fix: make the feedback dialog's privacy note match what is shared The note unconditionally said 'Your email address will be shared with the developer so they can respond', but AppFeedbackService shares the username always and the email only when it exists and is verified — an unverified or temp-user sender was promised a reply path that never materializes, and nobody was told about the username. Show 'username and email' when the signed-in user's email is verified, and 'username' otherwise. * fix: stop HTML-escaping email subject lines Subjects were compiled with default Handlebars escaping, so the app-user-feedback subject rendered a title like "Bob's App & Games" as "Bob&#x27;s App &amp; Games" — literal entities in the recipient's mail client. Subjects are plain-text headers, not HTML; compile them with noEscape. Header safety is unaffected: the transport encodes newlines and free-form values collapse whitespace upstream. * docs: state exactly what showFeedbackDialog shares with the developer The doc claimed the dialog 'tells the user their username will be shared', while the dialog's note talked only about the email address and the implementation shares the username always plus the email (as Reply-To) only when verified. Describe the actual disclosure: username always, email when verified. * docs: document the COOP false-resolve limitation of showFeedbackDialog Under COOP the popup's opener link is severed, so the SDK deliberately resolves false while the popup stays open and the user can still submit (a feedback submission has no server read-back the way a permission grant does). The documented contract ('resolves to true if the user submitted feedback') was silently wrong on cross-origin-isolated pages — state the limitation in the doc and the SDK jsdoc: false means 'not confirmed', not 'not sent'. * feat: point the feedback email footer at the Dev Center The footer told developers to turn feedback off via a puter.apps.update one-liner, but the toggle lives in the Dev Center app settings — and Dev Center is where apps get feedback enabled by default in the first place. Reword it to 'manage it in the Dev Center' with a link built from config.origin (like app_link) so it holds on self-hosted deployments. * test: cover the feedback service and store layers directly The service owns every feedback business rule — target resolution, eligibility, message normalization, the durable caps, and the owner-email preconditions — but was only reachable through the controller's tests. Give it and the store their own suites so a regression names the layer it broke. Service coverage adds the branches the route tests could not reach: a blocked origin resolving to null rather than surfacing a 403, owners who are suspended or unsubscribed, length measured after normalization, the 24h cap window boundary, subject-header injection via the app title, and the email links being rooted at config.origin. The two describes already labelled `AppFeedbackService ...` move out of the controller test, which keeps only the caller-facing promise that a failed send still returns success. * refactor: prep the feedback cap error once instead of via a factory Both throw sites are in one call and only one can ever run, so a plain const reads the same and drops a function that existed only to defer a constructor. * Require verified users for app feedback API Add `requireVerified: true` to both app feedback routes (`GET /target` and `POST /`) in `AppFeedbackController`. This tightens access control so only verified user accounts can fetch feedback targets or submit app feedback.	2026-08-12 09:49:24 -07:00