BPP — Bibliografia Publikacji Pracowników

Wsparcie komercyjne zapewnia

O projekcie

Bibliografia Publikacji Pracowników to system informatyczny do zarządzania bibliografią publikacji pracowników naukowych. Oprogramowanie przeznaczone jest dla bibliotek naukowych i uniwersyteckich w Polsce.

Oprogramowanie dystrybuowane jest na zasadach otwartoźródłowej licencji MIT.

Główne funkcje

• Zarządzanie bibliografią publikacji pracowników naukowych
• Integracja z Polską Bibliografią Naukową (PBN)
• Integracja z ORCID i CrossRef
• Raporty ewaluacyjne i analiza slotów
• Ranking autorów i punktacja publikacji
• Klasyfikacja i śledzenie Open Access
• Import i eksport danych z zewnętrznych systemów
• System zgłaszania publikacji przez pracowników
• Powiadomienia w czasie rzeczywistym

Wymagania systemowe

• PostgreSQL
• Redis
• Docker (zalecany sposób wdrożenia)

Instalacja

Wdrożenie produkcyjne BPP odbywa się przez repozytorium bpp-deploy. Tam znajdziesz kompletny zestaw plików docker compose, konfiguracji nginx i skryptów uruchomieniowych przygotowanych pod realny serwer.

Dwa podstawowe źródła informacji o instalacji:

• github.com/iplweb/bpp-deploy — gotowe pliki deploymentu (Docker Compose, nginx, named volumes, upgrade workflow).
• bpp.iplweb.pl/zrodla — opis procesu wdrożeniowego krok po kroku.

Oficjalne obrazy Dockera publikowane są pod iplweb/bpp_appserver i iplweb/bpp_dbserver (status buildu — zobacz badge „Docker" na górze strony).

Jeśli zamiast wdrożenia chcesz rozwijać kod BPP lokalnie, przejdź do sekcji Praca nad kodem (Linux) poniżej.

Wersja demo

Live-demo serwisu dostępne jest na żądanie — prosimy o kontakt pod adresem e-mail michal.dtz@gmail.com.

Praca nad kodem (Linux)

To NIE jest instrukcja wdrożenia produkcyjnego. Jeżeli chcesz zainstalować BPP na serwerze, skorzystaj z repozytorium bpp-deploy. Poniższe kroki opisują wyłącznie konfigurację lokalnego środowiska deweloperskiego i uruchamianie testów.

Pierwsze wykonanie poniższych kroków może trwać bardzo długo — ściągane są zależności Pythona, paczki npm/yarn, przeglądarki Playwright oraz obrazy Dockera dla testcontainers (PostgreSQL, Redis). Łącznie kilkaset MB do kilku GB transferu sieciowego. Pod każdym krokiem podany jest sposób, jak włączyć szczegółowe logowanie postępu.

Skrót — szybki start (TL;DR)

Od zera do zielonych testów (macOS / Linux):

git clone https://github.com/iplweb/bpp.git && cd bpp
make prepare-developer-machine    # systemowe libki + uv sync + playwright
make assets                       # yarn install + grunt build + compilemessages
uv run pytest -n auto             # testy równolegle (pytest-xdist)

Wymagania: Docker daemon (do testcontainers), Homebrew (macOS) lub apt + sudo (Linux). Pierwszy bieg pobiera kilkaset MB do paru GB (pakiety npm, przeglądarki Playwright, obrazy Dockera dla testów).

Co robi make prepare-developer-machine:

• macOS (Apple Silicon, Homebrew) — przez brew: cairo, pango, gdk-pixbuf, libffi, gobject-introspection, gtk+3, node, yarn; przez npm globalnie grunt-cli; tworzy sudo-symlinki w /usr/local/lib na libki z /opt/homebrew/lib (dyld nie konsultuje brew-owej ścieżki domyślnie, a DYLD_FALLBACK_LIBRARY_PATH jest stripowana przez SIP w podprocesach — patrz docs/MACOS_WEASYPRINT.md); na końcu uv sync --frozen --no-install-project --all-extras + uv run playwright install.
• Linux (Debian/Ubuntu, apt) — przez sudo apt: yarnpkg, nodejs, npm, python3-dev, libpq-dev, libcairo2-dev, libpango1.0-dev, libgdk-pixbuf2.0-dev, libffi-dev, libgirepository1.0-dev, libgtk-3-dev; przez sudo npm globalnie grunt-cli; na końcu uv sync --frozen --no-install-project --all-extras + uv run playwright install --with-deps (z systemowymi libkami chromium — wymaga sudo).

Auto-detekcja systemu jest domyślna; aby wymusić wariant: make prepare-developer-machine-macos albo make prepare-developer-machine-linux. Cel nie woła make assets — frontend trzeba zbudować osobno.

pytest -n auto (pytest-xdist) rozdziela testy między workery; każdy worker dostaje własny testcontainer PostgreSQL/Redis na losowym porcie, więc nie ma kolizji. Kolejne biegi z PYTEST_TESTCONTAINERS_REUSE=1 są znacznie szybsze (kontenery nie znikają między uruchomieniami).

Jeżeli przeglądarki Playwright trzeba zainstalować osobno (np. po samodzielnym uv sync), bez resetowania reszty środowiska:

make playwright-install

Poniżej szczegółowy opis krok po kroku — gdy chcesz wiedzieć, co dokładnie robi każdy etap albo musisz wykonać tylko fragment.

1. Sklonuj repozytorium

git clone https://github.com/iplweb/bpp.git
cd bpp

2. Zainstaluj zależności Pythona i Playwright

uv sync
uv run playwright install
sudo playwright install-deps

uv sync instaluje pakiety potrzebne do pracy i testów (pytest, pytest-django, model-bakery, ruff, pre-commit, …) — siedzą one w [dependency-groups].dev, którą uv aktywuje defaultowo (opt-out przez --no-dev). uv run playwright install pobiera przeglądarki używane w testach E2E (~500 MB). sudo playwright install-deps doinstalowuje systemowe biblioteki, których wymagają te przeglądarki (libnss3, libatk, libgtk-3, …) — wymaga sudo, bo używa apt.

Aby uzyskać dodatkowe logowanie postępu:

• uv sync -v — verbose output uv
• uv run playwright install --with-deps — alternatywa, która sama wywołuje apt (jeśli wolisz nie rozdzielać kroku z sudo)

3. Zbuduj assety frontendowe

make assets

Ten krok uruchamia yarn install (pierwszy raz pobiera kilkaset MB zależności Node.js do node_modules/), następnie grunt build (kompilacja SCSS → CSS, bundling JS) oraz compilemessages (tłumaczenia Django). Pierwsze wykonanie trwa kilka minut.

Aby zobaczyć szczegółowy postęp:

yarn install --verbose      # zanim uruchomisz make assets
grunt build --verbose       # alternatywa dla `make grunt-build`

4. Uruchom testy

uv run pytest

Pytest startuje własne kontenery Docker (PostgreSQL, Redis) przez plugin pytest-testcontainers-django — przy pierwszym uruchomieniu pobiera obrazy z Docker Hub (kolejne kilkaset MB). Wymagany jest działający Docker daemon.

Pełen suite może trwać do 10 minut. Domyślnie pytest-sugar pokazuje pasek postępu, ale jeśli chcesz więcej szczegółów:

uv run pytest -v                 # wypisuj nazwę każdego testu
uv run pytest -vv -s             # + nieprzechwycony stdout (print, logi)
make tests-without-playwright    # szybki wariant bez testów E2E

Reuse kontenerów testowych między uruchomieniami (znacznie szybsze kolejne biegi):

PYTEST_TESTCONTAINERS_REUSE=1 uv run pytest

Szybkie uruchomienie wersji deweloperskiej (run_site)

Komenda manage.py run_site uruchamia kompletny lokalny stack BPP w testcontainerach (PostgreSQL + Redis na losowych portach), więc można mieć kilka konfiguracji obok siebie bez konfliktów portów.

# Z baseline.sql (pusta baza demo):
uv run python src/manage.py run_site

# Z dump-em produkcyjnym (autodetect formatu):
uv run python src/manage.py run_site --from-dump ~/backups/bpp.pg_dump

Co robi:

1. Startuje PostgreSQL + Redis w kontenerach Docker na losowych portach.
2. Odtwarza dump (.sql / .sql.gz / .dump / .pg_dump / .pgdump) lub baseline (jeśli --from-dump nie podany).
3. Wykonuje migrate --noinput.
4. Tworzy lub nadpisuje superusera admin / admin z czyszczeniem wymogu zmiany hasła (świeży wpis w password_policies.PasswordHistory).
5. Drukuje banner z URL-ami i otwiera przeglądarkę na /admin/.
6. Odpala runserver na losowym wolnym porcie i blokuje.

Ctrl-C zatrzymuje runserver i sprząta kontenery.

Opcje:

Flaga	Działanie
--from-dump PATH	Restore z dump-a (autodetect po extension).
--with-celery	Dodatkowo odpala celery worker.
--no-browser	Nie otwiera przeglądarki.
--port PORT	Konkretny port runserver (default: losowy wolny).
--reuse	Reusuje istniejące named containery (szybszy restart).

Wymaganie: działający Docker daemon. Kontenery są ulotne — żyją tylko podczas trwania komendy (chyba że --reuse).

Technologie

Backend	Python 3.10+, Django 4.2, Celery, Django Channels
Baza danych	PostgreSQL
Cache / broker	Redis
Frontend	Foundation CSS, jQuery, HTMX, Select2
Infrastruktura	Docker, Nginx, Prometheus, Grafana

Zgłaszanie problemów

• Klienci komercyjni — portal wsparcia: support.iplweb.pl
• Społeczność — zgłoszenia na GitHub: github.com/iplweb/bpp/issues
• Luki bezpieczeństwa — nie otwieraj publicznego issue. Zob. SECURITY.md — preferowany kanał: GitHub Security Advisory.

Dokumentacja

Dokumentacja dostępna jest na stronie bpp.readthedocs.io.

Rozwój

Chcesz pomóc w rozwoju projektu? Przeczytaj CONTRIBUTING.md.

Licencja

MIT