MokoGitea license system integration for premium add-on validation #202

New Issue

2026-06-06T17:36:38Z

jmiller commented

2026-06-06 17:36:38 +00:00

Summary

Integrate MokoWaaS+ERP with the MokoGitea license system to validate license keys for premium add-on components (POS, MRP, and future paid modules). This enables per-component licensing where not all features are available to all clients.

Parent issue: #192

How It Works

License Validation Flow

Premium add-on installed (e.g., com_mokopos)
Admin enters DLID/license key in add-on config
Plugin validates key against MokoGitea license API
Valid → add-on enabled, features accessible
Invalid/expired → add-on disabled, shows license required message

Components Requiring Licenses

Component	Package	License Type
`com_mokopos`	POS	Premium add-on
`com_mokomrp`	MRP	Premium add-on
`pkg_mokowaas`	Base ERP	Base license (existing DLID)
Future add-ons	TBD	Per-component

Integration Points

Validate against MokoGitea license/update server API
Store validation state locally (cache with TTL to avoid constant API calls)
Heartbeat includes license status for each installed add-on
License expiry warnings in admin dashboard
Grace period on network failures (don't disable immediately if API unreachable)

Implementation

Extend plg_system_mokowaas_erp or new plg_system_mokowaas_license
License check on onAfterInitialise (cached, not every request)
Admin UI: License status panel in com_mokowaas dashboard
REST API: /v1/mokowaas/licenses — list installed add-on license statuses

Social Login / Google OAuth Piggyback

The Google OAuth email setup (#198) can leverage the existing MokoWaaS social login plugin for OAuth token management — reuse the same Google OAuth credentials/flow rather than building a separate OAuth implementation.

## Summary Integrate MokoWaaS+ERP with the MokoGitea license system to validate license keys for premium add-on components (POS, MRP, and future paid modules). This enables per-component licensing where not all features are available to all clients. **Parent issue:** #192 ## How It Works ### License Validation Flow 1. Premium add-on installed (e.g., `com_mokopos`) 2. Admin enters DLID/license key in add-on config 3. Plugin validates key against MokoGitea license API 4. Valid → add-on enabled, features accessible 5. Invalid/expired → add-on disabled, shows license required message ### Components Requiring Licenses | Component | Package | License Type | |-----------|---------|-------------| | `com_mokopos` | POS | Premium add-on | | `com_mokomrp` | MRP | Premium add-on | | `pkg_mokowaas` | Base ERP | Base license (existing DLID) | | Future add-ons | TBD | Per-component | ### Integration Points - Validate against MokoGitea license/update server API - Store validation state locally (cache with TTL to avoid constant API calls) - Heartbeat includes license status for each installed add-on - License expiry warnings in admin dashboard - Grace period on network failures (don't disable immediately if API unreachable) ### Implementation - Extend `plg_system_mokowaas_erp` or new `plg_system_mokowaas_license` - License check on `onAfterInitialise` (cached, not every request) - Admin UI: License status panel in `com_mokowaas` dashboard - REST API: `/v1/mokowaas/licenses` — list installed add-on license statuses ## Social Login / Google OAuth Piggyback The Google OAuth email setup (#198) can leverage the existing MokoWaaS social login plugin for OAuth token management — reuse the same Google OAuth credentials/flow rather than building a separate OAuth implementation.

jmiller commented

2026-06-06 17:37:00 +00:00

Update: Organization-level license interface

The license system is attached to a MokoGitea organization, not individual users. This means:

How It Works

MokoConsulting org owns the license definitions on MokoGitea
Clients (WaaS tenants) don't need their own MokoGitea accounts
Instead, clients piggyback on the MokoGitea interface via an org-scoped API key
The API key is tied to the organization and validates licenses for that org's products

Flow

Client installs com_mokopos
  → Enters DLID (license key)
  → MokoWaaS plugin calls MokoGitea license API with:
      - org API key (built into MokoWaaS, scoped to MokoConsulting org)
      - client DLID (per-site license)
  → MokoGitea validates: is this DLID valid for this product under this org?
  → Returns: valid/invalid, expiry date, licensed features

Benefits

Clients never touch MokoGitea directly
Org manages all license keys centrally
Same API key works for all MokoWaaS products (base ERP, POS, MRP)
License status reported in heartbeat back to MokoWaaSBase control panel

## Update: Organization-level license interface The license system is **attached to a MokoGitea organization**, not individual users. This means: ### How It Works - MokoConsulting org owns the license definitions on MokoGitea - Clients (WaaS tenants) don't need their own MokoGitea accounts - Instead, clients **piggyback on the MokoGitea interface via an org-scoped API key** - The API key is tied to the organization and validates licenses for that org's products ### Flow ``` Client installs com_mokopos → Enters DLID (license key) → MokoWaaS plugin calls MokoGitea license API with: - org API key (built into MokoWaaS, scoped to MokoConsulting org) - client DLID (per-site license) → MokoGitea validates: is this DLID valid for this product under this org? → Returns: valid/invalid, expiry date, licensed features ``` ### Benefits - Clients never touch MokoGitea directly - Org manages all license keys centrally - Same API key works for all MokoWaaS products (base ERP, POS, MRP) - License status reported in heartbeat back to MokoWaaSBase control panel

jmiller commented

2026-06-06 17:37:19 +00:00

Update: Separate plugin + service-based licensing

Separate Plugin

The license system will be its own plugin: plg_system_mokowaas_license — not part of plg_system_mokowaas_erp. This keeps licensing decoupled from ERP functionality, so it can validate licenses for ANY MokoWaaS add-on (ERP, POS, MRP, future products).

plg_system_mokowaas           → core
plg_system_mokowaas_firewall  → security
plg_system_mokowaas_tenant    → restrictions
plg_system_mokowaas_monitor   → heartbeat
plg_system_mokowaas_offline   → offline mode
plg_system_mokowaas_erp       → ERP engine
plg_system_mokowaas_license   → license validation  ← THIS

Services Attached to License Key Packages

License keys aren't just product keys — they unlock service packages that bundle features together:

License Package	Includes
MokoWaaS Base	CMS, firewall, tenant mgmt, health monitoring, helpdesk
MokoWaaS+ERP	Base + ERP contacts, pipeline, deals, activities, invoicing, inventory, e-signature
MokoWaaS+ERP+POS	ERP + Point of Sale
MokoWaaS+ERP+MRP	ERP + Manufacturing
MokoWaaS+ERP+Full	Everything

Each DLID maps to a service package. The license plugin checks which services are included and enables/disables features accordingly. This means:

A single DLID can unlock multiple services
Service packages can be upgraded without changing the license key
New services can be added to existing packages server-side
The plugin queries: "what services does this DLID include?" not just "is this DLID valid?"

API Response Shape

{
  "valid": true,
  "expiry": "2027-06-06",
  "package": "erp-pos",
  "services": ["base", "erp", "pos"],
  "features": {
    "max_contacts": -1,
    "max_terminals": 5,
    "max_users": 25
  }
}

## Update: Separate plugin + service-based licensing ### Separate Plugin The license system will be its own plugin: **`plg_system_mokowaas_license`** — not part of `plg_system_mokowaas_erp`. This keeps licensing decoupled from ERP functionality, so it can validate licenses for ANY MokoWaaS add-on (ERP, POS, MRP, future products). ``` plg_system_mokowaas → core plg_system_mokowaas_firewall → security plg_system_mokowaas_tenant → restrictions plg_system_mokowaas_monitor → heartbeat plg_system_mokowaas_offline → offline mode plg_system_mokowaas_erp → ERP engine plg_system_mokowaas_license → license validation ← THIS ``` ### Services Attached to License Key Packages License keys aren't just product keys — they unlock **service packages** that bundle features together: | License Package | Includes | |----------------|----------| | **MokoWaaS Base** | CMS, firewall, tenant mgmt, health monitoring, helpdesk | | **MokoWaaS+ERP** | Base + ERP contacts, pipeline, deals, activities, invoicing, inventory, e-signature | | **MokoWaaS+ERP+POS** | ERP + Point of Sale | | **MokoWaaS+ERP+MRP** | ERP + Manufacturing | | **MokoWaaS+ERP+Full** | Everything | Each DLID maps to a service package. The license plugin checks which services are included and enables/disables features accordingly. This means: - A single DLID can unlock multiple services - Service packages can be upgraded without changing the license key - New services can be added to existing packages server-side - The plugin queries: "what services does this DLID include?" not just "is this DLID valid?" ### API Response Shape ```json { "valid": true, "expiry": "2027-06-06", "package": "erp-pos", "services": ["base", "erp", "pos"], "features": { "max_contacts": -1, "max_terminals": 5, "max_users": 25 } } ```

jmiller commented

2026-06-06 17:37:48 +00:00

Update: Customer portal license visibility

License information should be accessible on the frontend customer portal so clients can self-service their subscription status:

Customer Portal View

Current license package and tier (Base, ERP, ERP+POS, etc.)
Active services list with status indicators
License expiry date and renewal info
Feature limits and current usage (e.g., "15 of 25 users", "3 of 5 POS terminals")
Upgrade options — see available packages they don't have yet
License key display (masked, with copy button)

Implementation

New frontend view in com_mokowaas: ?view=license or ?view=portal&layout=license
Pulls cached license data from plg_system_mokowaas_license
Access-controlled: only logged-in users with admin/manager group
No direct MokoGitea API calls from frontend — reads cached validation result

## Update: Customer portal license visibility License information should be accessible on the **frontend customer portal** so clients can self-service their subscription status: ### Customer Portal View - Current license package and tier (Base, ERP, ERP+POS, etc.) - Active services list with status indicators - License expiry date and renewal info - Feature limits and current usage (e.g., "15 of 25 users", "3 of 5 POS terminals") - Upgrade options — see available packages they don't have yet - License key display (masked, with copy button) ### Implementation - New frontend view in `com_mokowaas`: `?view=license` or `?view=portal&layout=license` - Pulls cached license data from `plg_system_mokowaas_license` - Access-controlled: only logged-in users with admin/manager group - No direct MokoGitea API calls from frontend — reads cached validation result

jmiller commented

2026-06-06 17:38:03 +00:00

Update: License key entry/update from frontend

Clients should be able to enter and update their DLID/license key directly from the MokoWaaS frontend portal — not just the admin backend.

Frontend License Management

Enter new license key — first-time setup from the customer portal
Update/replace license key — upgrade package without going into Joomla admin
Validate on submit — real-time validation against MokoGitea API, show result immediately
Re-validate button — force re-check current license (e.g., after an upgrade is applied server-side)

Flow

Client logs into frontend portal
  → Navigates to License / Subscription page
  → Sees current license status + services
  → Enters or updates DLID
  → Submit → plg_system_mokowaas_license validates against MokoGitea
  → Success: page refreshes with updated services/features
  → Failure: error message with instructions (contact support, check key, etc.)

This means the license plugin needs a frontend controller that accepts POST from the portal view, validates, and stores the updated key — not just a backend plugin config field.

## Update: License key entry/update from frontend Clients should be able to **enter and update their DLID/license key** directly from the MokoWaaS frontend portal — not just the admin backend. ### Frontend License Management - **Enter new license key** — first-time setup from the customer portal - **Update/replace license key** — upgrade package without going into Joomla admin - **Validate on submit** — real-time validation against MokoGitea API, show result immediately - **Re-validate** button — force re-check current license (e.g., after an upgrade is applied server-side) ### Flow ``` Client logs into frontend portal → Navigates to License / Subscription page → Sees current license status + services → Enters or updates DLID → Submit → plg_system_mokowaas_license validates against MokoGitea → Success: page refreshes with updated services/features → Failure: error message with instructions (contact support, check key, etc.) ``` This means the license plugin needs a **frontend controller** that accepts POST from the portal view, validates, and stores the updated key — not just a backend plugin config field.

jmiller referenced this issue

2026-06-06 17:38:26 +00:00

Expand MokoWaaS+ERP into full ERP offering — Joomla-native CMS + ERP platform #192

jmiller referenced this issue from a commit

2026-06-06 20:30:15 +00:00

feat: Sprint 5 — Reports, License Plugin, com_mokoshop, coupons, CNAME (#192, #202)

Sign in to join this conversation.

Priority Medium

Type Feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: MokoConsulting/MokoSuite#202