Никаких синтетических мок-серверов OnlyOffice — только интеграционные тесты
против живого инстанса (//go:build integration, skip без кред). Unit — чистые
парсеры/сериализация/SQL-билдеры.
Все bulk-вызовы через DoRetry. Секретов в git нет, только .env.example.
Новые эндпоинты — сначала в библиотеку, CLI — тонкая обёртка.
Задачи (дети)
F1 — канонический Entry + FileStore/Searcher; адаптеры REST и WebDAV
F4 — фасад «один клиент», миграция CLI/TUI на интерфейс
F5 — docs: единый контракт и как выбирать бэкенд
DoD эпика
REST/DAV/PG/ES доступны через один интерфейс; дублирующей логики нет.
Поиск по содержимому документов работает (ES) и доступен из CLI.
go build ./... && go vet ./... && go test ./... зелёные; интеграционные — go test -tags=integration ./... на живом OO.
Рефакторинг не ломает публичный API (*Client методы сохранены или
помечены deprecated с миграцией).
## Эпик: единый файловый клиент go-onlyoffice (REST · WebDAV · PostgreSQL · Elasticsearch)
### Цель
Свести доступ к файлам в **одну внутреннюю абстракцию** внутри библиотеки
`go-onlyoffice`, а не надстраивать новый слой поверх. Сейчас параллельно живут:
- OnlyOffice REST (`files.go`, `/api/2.0/files`),
- WebDAV-контур (`files_webdav.go`, наш `oo-webdav`),
- MinIO/S3 fallback (`storage_fallback.go`),
а нужно ещё:
- **PostgreSQL** — прямой доступ к БД Community Server (read-only),
- **Elasticsearch** — полнотекстовый поиск (индекс `files_file`, контент
`document.attachment.content`).
Библиотека — единственное место, где это реализовано один раз; CLI/TUI/потребители
ходят через один интерфейс.
### Архитектура (согласуется в F1)
- Каноническая модель `Entry` (file/folder) + `Kind`.
- Интерфейс `FileStore`: `List/Stat/CreateFolder/Upload/Download/Move/Copy/Rename/Delete`.
- Опциональный `Searcher`: `Search(SearchQuery) ([]SearchHit, error)` —
имя и **содержимое** (ES).
- Бэкенды: REST, WebDAV, PostgreSQL (read-only), Elasticsearch (поиск).
- Фасад: один `*Client` для файлов; выбор/композиция бэкендов (REST/DAV — запись,
PG — быстрые чтения, ES — контент-поиск).
### Правила репо (не нарушать)
- Плоский пакет `onlyoffice`, **без** `internal/`/`pkg/*` подпакетов; бэкенды —
файлами (`file_rest.go`, `file_dav.go`, `file_pg.go`, `file_es.go`), не пакетами.
- **Никаких синтетических мок-серверов OnlyOffice** — только интеграционные тесты
против живого инстанса (`//go:build integration`, skip без кред). Unit — чистые
парсеры/сериализация/SQL-билдеры.
- Все bulk-вызовы через `DoRetry`. Секретов в git нет, только `.env.example`.
- Новые эндпоинты — сначала в библиотеку, CLI — тонкая обёртка.
### Задачи (дети)
- [ ] F1 — канонический `Entry` + `FileStore`/`Searcher`; адаптеры REST и WebDAV
- [ ] F2 — PostgreSQL-бэкенд (read-only, изнутри)
- [ ] F3 — Elasticsearch-клиент поиска (имя + контент) + `oo search`
- [ ] F4 — фасад «один клиент», миграция CLI/TUI на интерфейс
- [ ] F5 — docs: единый контракт и как выбирать бэкенд
### DoD эпика
- [ ] REST/DAV/PG/ES доступны через один интерфейс; дублирующей логики нет.
- [ ] Поиск по содержимому документов работает (ES) и доступен из CLI.
- [ ] `go build ./... && go vet ./... && go test ./...` зелёные; интеграционные —
`go test -tags=integration ./...` на живом OO.
- [ ] Рефакторинг не ломает публичный API (`*Client` методы сохранены или
помечены deprecated с миграцией).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Эпик: единый файловый клиент go-onlyoffice (REST · WebDAV · PostgreSQL · Elasticsearch)
Цель
Свести доступ к файлам в одну внутреннюю абстракцию внутри библиотеки
go-onlyoffice, а не надстраивать новый слой поверх. Сейчас параллельно живут:files.go,/api/2.0/files),files_webdav.go, нашoo-webdav),storage_fallback.go),а нужно ещё:
files_file, контентdocument.attachment.content).Библиотека — единственное место, где это реализовано один раз; CLI/TUI/потребители
ходят через один интерфейс.
Архитектура (согласуется в F1)
Entry(file/folder) +Kind.FileStore:List/Stat/CreateFolder/Upload/Download/Move/Copy/Rename/Delete.Searcher:Search(SearchQuery) ([]SearchHit, error)—имя и содержимое (ES).
*Clientдля файлов; выбор/композиция бэкендов (REST/DAV — запись,PG — быстрые чтения, ES — контент-поиск).
Правила репо (не нарушать)
onlyoffice, безinternal//pkg/*подпакетов; бэкенды —файлами (
file_rest.go,file_dav.go,file_pg.go,file_es.go), не пакетами.против живого инстанса (
//go:build integration, skip без кред). Unit — чистыепарсеры/сериализация/SQL-билдеры.
DoRetry. Секретов в git нет, только.env.example.Задачи (дети)
Entry+FileStore/Searcher; адаптеры REST и WebDAVoo searchDoD эпика
go build ./... && go vet ./... && go test ./...зелёные; интеграционные —go test -tags=integration ./...на живом OO.*Clientметоды сохранены илипомечены deprecated с миграцией).
Дети: F1 #35 (модель+интерфейс, REST/DAV) → F4 #38 (фасад/миграция). Параллельно: F2 #36 (PostgreSQL), F3 #37 (Elasticsearch-поиск, приоритет — контент-поиск). F5 #39 docs. Порядок: F1 → (F2 ∥ F3) → F4 → F5.
Добавлен F6 #42 (PDF-контент в ES).
Эпик закрыт: F1 #35, F2 #36, F3 #37, F4 #38, F5 #39, F6 #42 — все merged. Единый файловый клиент: Entry/FileStore/Searcher + FileClient (REST/WebDAV/SQL(MySQL/PG)/Elasticsearch), oo search/o index, docs/unified-file-client.md, docs/elasticsearch.md.