Removed admin pages and roadmap
Fixed .gitignore
This commit is contained in:
17
.gitignore
vendored
17
.gitignore
vendored
@@ -4,27 +4,14 @@
|
|||||||
|
|
||||||
# Hugo module cache
|
# Hugo module cache
|
||||||
/hugo_cache/
|
/hugo_cache/
|
||||||
|
.hugo_build.lock
|
||||||
|
|
||||||
# Node.js (if using npm for assets/tooling)
|
# Node.js
|
||||||
node_modules/
|
node_modules/
|
||||||
npm-debug.log*
|
|
||||||
yarn-debug.log*
|
|
||||||
yarn-error.log*
|
|
||||||
|
|
||||||
# OS files
|
# OS files
|
||||||
.DS_Store
|
.DS_Store
|
||||||
Thumbs.db
|
Thumbs.db
|
||||||
|
|
||||||
# Editor files
|
|
||||||
.vscode/
|
|
||||||
.idea/
|
|
||||||
*.swp
|
|
||||||
*.swo
|
|
||||||
|
|
||||||
# Environment / secrets
|
|
||||||
.env
|
|
||||||
.env.local
|
|
||||||
.env.*.local
|
|
||||||
|
|
||||||
# Other
|
# Other
|
||||||
/assets/jsconfig.json
|
/assets/jsconfig.json
|
||||||
|
|||||||
@@ -1,12 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 193
|
|
||||||
title: "Admin Guide"
|
|
||||||
description: "Internal documentation for Federated Computer staff with admin access."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.** This section is intended for Federated Computer staff with admin access. Do not share this content publicly or include it in external-facing documentation.
|
|
||||||
@@ -1,32 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 195
|
|
||||||
title: "Adjusting Balances"
|
|
||||||
description: "How to manually credit or debit an account's balance."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.**
|
|
||||||
|
|
||||||
Admins can manually credit or debit an account's balance. This is used for issuing manual credits (goodwill adjustments, refunds, promotions) or correcting erroneous balance entries.
|
|
||||||
|
|
||||||
## How to Adjust a Balance
|
|
||||||
|
|
||||||
1. Open the account in the Admin panel.
|
|
||||||
2. Navigate to the **Balance** section.
|
|
||||||
3. Click **Adjust Balance**.
|
|
||||||
4. Choose the adjustment type: **Credit** or **Debit**.
|
|
||||||
5. Enter the amount in dollars (minimum $0.01).
|
|
||||||
6. Enter a **reason/description** for the adjustment. This is recorded in the transaction history and visible to account owners.
|
|
||||||
7. Confirm.
|
|
||||||
|
|
||||||
## Credits vs Debits
|
|
||||||
|
|
||||||
**Credit** — Adds funds to the account's balance. The account can use these funds toward future charges. Use credits for goodwill adjustments, service credits, or correcting undercharges.
|
|
||||||
|
|
||||||
**Debit** — Removes funds from the account's balance. Use debits to correct accidental credits or to reclaim balance for a specific reason. A debit cannot reduce the balance below zero — if the requested debit exceeds the available balance, it will fail.
|
|
||||||
|
|
||||||
> **Best Practice:** Always include a clear, specific description when adjusting a balance. Descriptions like "Goodwill credit — service outage 2024-11" are far more useful than generic notes like "adjustment". These are visible in the transaction history and may be referenced by support or finance.
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 198
|
|
||||||
title: "Invoices and Retrying Failed Payments"
|
|
||||||
description: "How to view invoices, void open charges, and manually retry failed payments."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.**
|
|
||||||
|
|
||||||
Admins can view all invoices for any account, void open invoices, and manually trigger a retry on failed payments.
|
|
||||||
|
|
||||||
## Viewing Invoices
|
|
||||||
|
|
||||||
From an account's detail page, click **View Invoices** to see all invoices for that account. Each invoice shows its type, amount, date, period, status, and any retry attempts with their outcomes.
|
|
||||||
|
|
||||||
## Invoice Statuses
|
|
||||||
|
|
||||||
- `open` — Invoice has been created but payment has not been collected (either pending or failed).
|
|
||||||
- `paid` — Payment was successfully collected.
|
|
||||||
- `void` — Invoice has been voided. No payment will be attempted.
|
|
||||||
|
|
||||||
## Voiding an Invoice
|
|
||||||
|
|
||||||
Only `open` invoices can be voided. Voiding an invoice cancels any pending retry attempts and marks the invoice as permanently closed. Use this when a charge should not be collected — for example, if a billing error occurred and the charge is not owed.
|
|
||||||
|
|
||||||
To void an invoice, open the invoice detail and click **Void Invoice**. Confirm the action. This cannot be undone.
|
|
||||||
|
|
||||||
> **Caution:** Voiding an invoice does not issue a refund if the invoice was already paid. Only open invoices can be voided. For paid invoices that require a reversal, use a balance credit to compensate the account.
|
|
||||||
|
|
||||||
## Retrying a Failed Payment
|
|
||||||
|
|
||||||
The system automatically retries failed payments on a schedule (3 days, 7 days, 14 days after failure). If you need to trigger a retry manually — for example, after a customer has updated their card — you can do so from the invoice detail view by clicking **Retry Now**.
|
|
||||||
|
|
||||||
## Regenerating Invoice PDFs
|
|
||||||
|
|
||||||
If an invoice PDF was not generated correctly, you can regenerate it from the invoice detail view using the **Regenerate PDF** action. The new PDF will be stored and available for the customer to download.
|
|
||||||
|
|
||||||
## Payment Failure and Account Suspension
|
|
||||||
|
|
||||||
If all automatic retry attempts fail, the account may be suspended automatically. At that point, an admin can either manually retry the payment after the customer resolves their payment issue, or change the account status to reflect the appropriate resolution.
|
|
||||||
@@ -1,45 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 194
|
|
||||||
title: "Managing Accounts"
|
|
||||||
description: "How to view, suspend, reactivate, and cancel customer accounts."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.**
|
|
||||||
|
|
||||||
Admins can view all accounts, inspect their details, and change their status from the admin panel. Navigate to **Admin → Accounts** to see a list of all accounts with summary information.
|
|
||||||
|
|
||||||
## Viewing an Account
|
|
||||||
|
|
||||||
Click any account to open the detail view. You'll see:
|
|
||||||
|
|
||||||
- Account details: company name, address, status, tier, Stripe customer ID
|
|
||||||
- Subscription details and any pending tier change
|
|
||||||
- Active subscription add-ons
|
|
||||||
- All users on the account with their roles
|
|
||||||
- Coupon history (codes applied and removed)
|
|
||||||
- Current account balance
|
|
||||||
|
|
||||||
## Account Statuses
|
|
||||||
|
|
||||||
An account can be in one of the following states:
|
|
||||||
|
|
||||||
- `pending_email` — Account created; user hasn't verified their email yet.
|
|
||||||
- `pending_checkout` — Email verified; awaiting checkout completion.
|
|
||||||
- `active` — Fully active, paying account.
|
|
||||||
- `suspended` — Account access is disabled. Cores are offline. Billing may still be running.
|
|
||||||
- `canceled` — Account has been terminated. Access is permanently revoked.
|
|
||||||
|
|
||||||
## Changing Account Status
|
|
||||||
|
|
||||||
From the account detail view, use the **Change Status** action to set an account to `active`, `suspended`, or `canceled`.
|
|
||||||
|
|
||||||
- **Suspending** an account sends a disable notification to the Provisioner, which takes Cores offline. The account owner receives a suspension notification email.
|
|
||||||
- **Reactivating** a suspended account sends an enable notification to the Provisioner, bringing Cores back online.
|
|
||||||
- **Canceling** permanently terminates the account. This action cannot be reversed through the admin panel. The account owner receives a cancellation email.
|
|
||||||
|
|
||||||
> **Caution:** Canceling an account is irreversible. Only cancel accounts when you are certain the action is correct. If you only need to temporarily disable access, use **Suspended** instead.
|
|
||||||
@@ -1,37 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 197
|
|
||||||
title: "Managing Coupons"
|
|
||||||
description: "How to create coupons, set usage limits, and control what they apply to."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.**
|
|
||||||
|
|
||||||
Coupons can be created and managed from **Admin → Coupons**. Coupons are currently applied at checkout only.
|
|
||||||
|
|
||||||
## Creating a Coupon
|
|
||||||
|
|
||||||
Click **Create Coupon** and fill in the following fields:
|
|
||||||
|
|
||||||
- **Code** — The code customers will enter at checkout. Codes are stored in uppercase and must be unique. Letters, numbers, and hyphens are recommended.
|
|
||||||
- **Type** — One of three discount types:
|
|
||||||
- `percent` — Percentage discount. Set *Value* to the percentage (e.g., `20` for 20% off).
|
|
||||||
- `fixed` — Fixed dollar discount. Set *Value* to the amount in cents (e.g., `5000` for $50 off).
|
|
||||||
- `free` — Covers the full charge. Value is ignored.
|
|
||||||
- **Value** — The discount amount (percentage or cents, per type above). Set to 0 for free-type coupons.
|
|
||||||
- **Max Uses** — Optional. Maximum number of times this coupon can be used. Leave blank for unlimited uses.
|
|
||||||
- **Covers Domains** — If checked, the discount also applies to domain registration costs at checkout. If unchecked, the discount applies to the plan fee only.
|
|
||||||
|
|
||||||
## Toggling a Coupon
|
|
||||||
|
|
||||||
Any coupon can be activated or deactivated. Deactivated coupons are rejected at checkout even if they haven't reached their usage limit. Use this to quickly disable a coupon without deleting it.
|
|
||||||
|
|
||||||
## Viewing Coupon Usage
|
|
||||||
|
|
||||||
The Coupons list shows each coupon's current use count alongside its limit. You can also see coupon history on individual account pages — this shows which coupon was applied, when, and whether it was later removed.
|
|
||||||
|
|
||||||
> **Note:** Coupons cannot currently be applied to post-signup billing. If a customer needs a recurring discount, use balance adjustments (credits) as an alternative.
|
|
||||||
@@ -1,51 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 196
|
|
||||||
title: "Managing Tiers"
|
|
||||||
description: "How to create, modify, and toggle plan tiers."
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-05-27T00:00:00-00:00"
|
|
||||||
lastmod: "2025-05-27T00:00:00-00:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
> **Internal use only.**
|
|
||||||
|
|
||||||
Admins can view, create, modify, and toggle the active status of plan tiers from **Admin → Tiers**. Changes to tier pricing or limits affect new billing cycles going forward; they do not retroactively change existing invoices.
|
|
||||||
|
|
||||||
## Viewing Tiers
|
|
||||||
|
|
||||||
The Tiers page shows all tiers — both active and inactive — with their pricing and current settings.
|
|
||||||
|
|
||||||
## Editing an Existing Tier
|
|
||||||
|
|
||||||
Click on a tier to edit its details:
|
|
||||||
|
|
||||||
- **Name** — Display name shown to customers
|
|
||||||
- **Membership fee** — Monthly flat fee in cents
|
|
||||||
- **Per-Core price** — Monthly per-Core charge in cents
|
|
||||||
- **Credit cents** — Account credit included at signup (charged at checkout, loaded to balance)
|
|
||||||
- **Max Cores** — Maximum Cores allowed (0 = unlimited)
|
|
||||||
|
|
||||||
## Toggling Tier Availability
|
|
||||||
|
|
||||||
Each tier can be set to **active** or **inactive**. Inactive tiers are not visible or selectable by customers during checkout or plan changes. Existing accounts on an inactive tier are not affected — they remain on their current tier; only new sign-ups and tier changes are blocked.
|
|
||||||
|
|
||||||
## Creating a New Tier
|
|
||||||
|
|
||||||
Use the **Create Tier** button to define a new tier. You'll need to provide:
|
|
||||||
|
|
||||||
- A unique key (lowercase, no spaces — used internally and in the database, e.g. `enterprise_plus`)
|
|
||||||
- A display name
|
|
||||||
- Membership fee, per-Core price, credit cents, and max Cores
|
|
||||||
|
|
||||||
After creating a tier, you'll also need to configure its add-on pricing via the Add-on admin tools if you want that tier to support per-Core or subscription add-ons.
|
|
||||||
|
|
||||||
## Changing an Account's Tier (Admin Override)
|
|
||||||
|
|
||||||
From an account's detail view, admins can change that account's tier directly. This is separate from the customer-facing plan change flow. Admins can choose to apply the change **immediately** or **at the next billing cycle**.
|
|
||||||
|
|
||||||
- **Immediate** — Takes effect right away; new pricing applies from the current date.
|
|
||||||
- **Next billing cycle** — Behaves like a customer-initiated plan change.
|
|
||||||
|
|
||||||
> **Caution:** Immediate tier changes can affect an account's mid-cycle billing calculations. Use this sparingly and document the reason when performing immediate overrides.
|
|
||||||
@@ -1,24 +0,0 @@
|
|||||||
---
|
|
||||||
weight: 495
|
|
||||||
title: "Roadmap"
|
|
||||||
description: ""
|
|
||||||
icon: "article"
|
|
||||||
date: "2025-08-28T13:41:48-06:00"
|
|
||||||
lastmod: "2025-08-28T13:41:48-06:00"
|
|
||||||
draft: false
|
|
||||||
toc: true
|
|
||||||
---
|
|
||||||
|
|
||||||
Federated Computer is working on the following initiatives for the benefit of our customers and partners:
|
|
||||||
|
|
||||||
### Spring, 2026
|
|
||||||
|
|
||||||
**Computer.** Our take on a central web application for managing all SaaS workloads, dates, clients, messages.
|
|
||||||
|
|
||||||
### First Half, 2026
|
|
||||||
|
|
||||||
**Core Workflow Intelligence.** AI services for building application workflows combined between 2 or more open source SaaS applications.
|
|
||||||
|
|
||||||
### Second Half, 2026
|
|
||||||
|
|
||||||
**On Premise Provisioning of Federated Cores.** This will support customers that want to connect to high bandwidth, synchronous networks (eg Fiber) and have a Federated Core running on their own hardware with all the management services provided by Federated Core Platform.
|
|
||||||
Reference in New Issue
Block a user