# Design: Dwukanałowy system aktualizacji + zarządzanie licencjami

**Data:** 2026-02-28
**Status:** Zatwierdzony

## Kontekst

cmsPRO jest używany przez wielu klientów. Celem jest wprowadzenie dwustopniowej dystrybucji aktualizacji:
- Kanał **beta** — tylko wybrane testowe instalacje (1–2 strony dewelopera)
- Kanał **stable** — wszyscy pozostali klienci

Zarządzanie odbywa się z panelu admina na `cmspro.project-dc.pl` (ten sam serwer i DB co serwer aktualizacji).

**Kluczowe ograniczenie:** nowy moduł admina oraz nowe tabele DB nigdy nie trafiają do paczek aktualizacyjnych wysyłanych klientom.

---

## Sekcja 1: Baza danych

Dwie nowe tabele tworzone **ręcznie tylko na serwerze dewelopera**. Nie mogą pojawić się w żadnym SQL migracyjnym dla klientów.

```sql
CREATE TABLE pp_update_licenses (
  id               INT AUTO_INCREMENT PRIMARY KEY,
  `key`            VARCHAR(64) NOT NULL UNIQUE,
  domain           VARCHAR(255) NOT NULL,
  valid_to_date    DATE NULL,
  valid_to_version VARCHAR(10) NULL,
  beta             TINYINT(1) NOT NULL DEFAULT 0,
  note             TEXT NULL,
  created_at       DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at       DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

CREATE TABLE pp_update_versions (
  id           INT AUTO_INCREMENT PRIMARY KEY,
  version      VARCHAR(10) NOT NULL UNIQUE,
  channel      ENUM('beta','stable') NOT NULL DEFAULT 'beta',
  created_at   DATETIME DEFAULT CURRENT_TIMESTAMP,
  promoted_at  DATETIME NULL
);
```

Dane z `updates/versions.php` (tablica `$license`) migrujemy jednorazowo do `pp_update_licenses`.

---

## Sekcja 2: Plik `updates/versions.php`

Plik zostaje w tym samym miejscu, zmienia się tylko logika (hardkodowane tablice zastępowane odczytem z DB).

### Nowy przepływ:

1. `require_once '../config.php'` → dostęp do `$mdb` (Medoo)
2. Skan filesystem — lista istniejących ZIPów (jak dotychczas)
3. **Auto-discovery:** każdy ZIP nieobecny w `pp_update_versions` → `INSERT IGNORE` z `channel='beta'`. Wrzucenie nowego ZIPa na serwer automatycznie rejestruje go jako beta — bez zmian w `build-update.ps1`.
4. Walidacja klucza z `pp_update_licenses` (zamiast `$license[...]`)
5. Filtrowanie wersji według kanału:
   - klient z `beta=1` → wersje gdzie `channel IN ('beta','stable')`
   - klient z `beta=0` → tylko `channel='stable'`
6. Dalsze filtrowanie po `valid_to_date` i `valid_to_version` (bez zmian)
7. Wypisanie listy wersji (jak dotychczas)

---

## Sekcja 3: Nowy moduł admina `Releases`

Nowa nazwa `Releases` (odróżnienie od istniejącego modułu `Update` używanego przez klientów do aktualizacji własnej instalacji).

### Zakładka "Wersje"

- Tabela z `pp_update_versions` + status istnienia ZIPa na dysku
- Kolumny: wersja, kanał, data dodania, data promocji
- Akcje: **Promuj do stable** / **Cofnij do beta**

### Zakładka "Licencje"

- Tabela z `pp_update_licenses`
- Kolumny: domena, klucz (skrócony hash), ważna do daty, ważna do wersji, beta (toggle), notatka
- Pełny CRUD: dodaj / edytuj / usuń
- Szybki toggle flagi `beta` bezpośrednio z listy

### Pliki modułu

Wszystkie wykluczone z paczek ZIP dla klientów:

```
autoload/admin/controls/class.Releases.php
autoload/admin/factory/class.Releases.php
autoload/admin/view/class.Releases.php
admin/templates/releases/main-view.php
admin/templates/releases/licenses-view.php
```

---

## Sekcja 4: Wykluczenie z aktualizacji klientów

### Pliki PHP
W `build-update.ps1` — dodanie powyższych ścieżek do listy wykluczeń.

### Tabele DB
`pp_update_licenses` i `pp_update_versions` **nigdy** nie pojawiają się w:
- plikach `_sql.txt` dołączanych do paczek
- sekcji `sql` w plikach `_manifest.json`

Tabele tworzone jednorazowo ręcznie na serwerze dewelopera.

---

## Migracja danych

Jednorazowy skrypt PHP (uruchamiany ręcznie na serwerze) przenosi dane z `$license[...]` z `versions.php` do `pp_update_licenses`. Po migracji tablica `$license` w `versions.php` jest usuwana.