Adds new 'settings' form group (parent for project-level configuration
like variables and webhooks). Project variables become settings.root.
The backend migration library exposes them via the new GROUP_SETTINGS.
Adds api-key as a child toggle under the existing integrations group,
matching the parent-child pattern used by users/teams, databases/rows,
and messaging/messages. The backend uses the kebab-case 'api-key'
resource id; the form field stays camelCase as a local property.
* fix(backups): surface skipped scheduled backups with a Skipped label
Cloud now writes a terminal archive doc with status='skipped' for cron
ticks that were dropped because the previous run hadn't finished yet.
Map that to the neutral 'waiting' Status visual and override the label
so the user sees "Skipped" instead of the auto-capitalized "Waiting".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(backups): comment why 'skipped' maps to the 'waiting' visual
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pin every third-party action in .github/workflows/ to a full commit SHA
with a trailing version comment, and bump to the latest stable release.
Defends against tag-rewrite supply-chain attacks while keeping versions
legible.
The Fail/Skip/Overwrite radios are only rendered when the Databases
resource is checked. The local importOnDuplicate value, however,
persists across toggles — so unticking Databases after picking
Overwrite or Skip would silently apply that mode to the entire
migration payload (users, teams, functions, etc.) on submit.
Gate the value at submit time: only forward importOnDuplicate when
$formData.databases.root is true; otherwise always send Fail.
Addresses greptile P1 review on PR #2964.
Reworks the import-options UI in three places to match the new
OnDuplicate enum (Fail / Skip / Overwrite) shipped by the cloud worker
and migration package:
- Settings → Migrations wizard (Appwrite source): three-option radio
group with Fail pre-selected. Wording reflects that overwrite/skip
apply to the entire resource tree (databases, tables, columns,
indexes, rows), not just rows.
- Tables (TablesDB) CSV import: same three-option radio replacing
the prior two checkboxes. Wording stays document-centric since CSV
import is row-only.
- Collections (DocumentsDB) JSON import: previously imported with no
onDuplicate (silent default to fail). Now opens the same Import
options dialog with Fail/Skip/Overwrite radios.
Also bumps @appwrite.io/console SDK to https://pkg.vc/-/@appwrite/
@appwrite.io/console@341620a so the OnDuplicate enum exports match
the merged backend (post 1.9.x).
Renamed OnDuplicate.Upsert -> OnDuplicate.Overwrite throughout the
console (the enum was renamed in upstream PR #11910 / migration 1.9.7;
the prior reference compiled to undefined and silently defaulted the
backend to Fail).
Two issues surfaced during user testing of the live-payment flow on
create-organization and change-plan.
1. confirmPayment() in src/lib/stores/stripe.ts always called
resolve('/(console)/organization-[organization]/billing', {organization: orgId})
eagerly at the top of the try block. The create-organization callsite
passes only `route` (no orgId, since the team doesn't yet exist), so
resolve() threw on the missing required `organization` param, the
outer catch fired, and the user saw the generic
"There was an error processing your payment..." message instead of
the actual Stripe error. The URL is now built lazily — resolve() is
only invoked when no `route` is supplied. The outer catch now
surfaces the underlying error message (Stripe / SDK error) and falls
back to the generic copy only when no message is available.
2. When the frontend Stripe confirmation failed, the backend was never
notified, leaving draft teams (status='draft') and partial upgrades
stranded. handleTeamCreateUpgradeFailure already deletes drafts and
rolls back upgrades — but only when the backend recognises failure.
The create-organization and change-plan error branches now make a
best-effort call to organizations.validatePayment after a failed
confirmation. validatePayment inspects the actual Stripe intent and
routes to handleTeamCreateUpgradeFailure when it isn't
succeeded/processing. validatePayment is expected to throw
BILLING_PAYMENT_FAILED in this path; the throw is swallowed because
the user has already seen the underlying Stripe error and the
backend cleanup is the desired side-effect.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Prem Palanisamy
Aditya Oberai
Harsh Mahajan
harsh mahajan
Jake Barnby
Chirag Aggarwal
ArnabChatterjee20k
ArnabChatterjee20k
Damodar Lohani
Damodar Lohani