Przejdź do głównej treści

Możliwości w szczegółach

Pełna lista tego, co system potrafi dziś, według ról i modułów. Tylko to, co zrealizowane: nic z planów.

Dla każdego użytkownika

Logowanie i profil

  • Logowanie adresem e-mail i hasłem; sesja przedłuża się automatycznie.
  • Logowanie kontem uczelnianym lub przez zewnętrznego dostawcę tożsamości: przyciski bezpośrednio na stronie logowania.
  • Limit prób logowania z jednego adresu jako ochrona przed zgadywaniem hasła.
  • Przy błędnych danych system nie zdradza, co było błędne: e-mail czy hasło.
  • Zablokowane konto nie może się zalogować.
  • Po zalogowaniu osobisty panel z własnym menu dla każdej roli.
  • Profil: imię i nazwisko, login, e-mail, rola, numer indeksu, powiązane konta w systemach hostingu kodu, grupa, data rejestracji.
  • Edycja dozwolonych pól profilu: imię i nazwisko, numer indeksu, konto w systemie hostingu kodu i preferowany język.
  • Zmiana hasła z profilu z kontrolą długości i zgodności.
  • Przy pierwszym logowaniu system wymaga zmiany wydanego hasła.
  • Podpinanie i odpinanie zewnętrznych kont logowania bezpośrednio w profilu.
  • Język interfejsu: polski, angielski, rosyjski, białoruski; wybór jest zapamiętywany i stosowany na każdej stronie.
  • Daty i liczby w formacie wybranego języka.
  • Link „przejdź do treści” na każdej stronie dla obsługi z klawiatury.

Pomoc

  • Wbudowana pomoc dla studenta i wykładowcy: pierwsze kroki, przewodnik po ekranach i instrukcje krok po kroku.
  • Student widzi pomoc studenta, wykładowca widzi pomoc wykładowcy i studenta; pomoc dostępna w czterech językach interfejsu.

Praca z GitHubem i GitLabem

Jak system pracuje z hostingiem kodu

  • Kurs żyje w repozytorium: zadania, instrukcje, rubryki i szablony testów to pliki pod kontrolą wersji; wersja kursu to tag git, a zawartość pod tagiem jest niezmienna.
  • System nie przynosi własnego hostingu kodu: pracuje na GitHubie lub GitLabie uczelni przez konto bota i tokeny o minimalnych uprawnieniach.
  • Każdemu studentowi na każdy kurs system automatycznie tworzy prywatne osobiste repozytorium ze szkieletu: szablon raportu, zalążek kodu, testy publiczne, konfiguracja CI; prywatne materiały kursu nigdy tam nie trafiają.
  • Oddanie to pull request na GitHubie lub merge request na GitLabie; zdarzenie przychodzi webhookiem, a na wypadek jego utraty działa zapasowe odpytywanie otwartych żądań.
  • Automatyczne testy uruchamiają się w CI samego hostingu: GitHub Actions lub GitLab CI uczelni; system odczytuje status testu i nie uruchamia analizy AI przy czerwonym wyniku.
  • Do żądania trafia tylko neutralny komentarz z linkiem do systemu: bez punktów i treści informacji zwrotnej.
  • Force-push to to samo oddanie z nową rewizją, bez duplikatów; zdarzenia dla już ocenionej pracy są ignorowane.
  • Autoring kursu również idzie przez żądania: szkielet zadania, edycje plików i szablony CI są wysyłane jako żądanie z przeglądem, scalane dopiero po zatwierdzeniu.
  • Jedno centralne repozytorium automatycznych testów na organizację lub grupę; repozytoria kursów i studentów wskazują tag pływający, więc poprawki docierają bez commitów do każdego repozytorium.
  • Synchronizacja składu organizacji lub grupy z systemem: raport rozbieżności, zaproszenia dla brakujących, próbne uruchomienie bez zmian.
  • Do hostingu kodu trafia tylko login studenta: ani imię i nazwisko, ani e-mail, ani oceny.
  • Obaj dostawcy jednocześnie: użytkownik ma po jednym koncie na dostawcę, kurs ma jednego dostawcę, a domyślne tokeny i organizacje są ustawiane osobno dla każdego.

GitHub

  • GitHub.com i GitHub Enterprise Server: adres instancji ustawia się w tokenie.
  • Konto bota i dwa tokeny: jeden do członkostwa i zaproszeń, drugi do treści kursów.
  • Osobiste repozytoria studentów w organizacji uczelni; dostęp przez zaproszenie współpracownika, członkostwo w organizacji niewymagane, członkowie organizacji nie potrzebują zaproszenia.
  • Działa także na darmowym planie organizacji: brak ochrony gałęzi rekompensuje bramka przeglądu przy publikacji w samym systemie.
  • Webhook organizacji tylko na zdarzenia pull request z weryfikacją podpisu przed parsowaniem treści.
  • Wynik GitHub Actions odczytywany przez check-runs z zapasowym odczytem przez Actions API; gdy żadne nie jest dostępne, jawny błąd zamiast zielonego przejścia.
  • Student bez konta GitHub otrzymuje status „błąd” z przyczyną; nieudane utworzenia repozytoriów są ponawiane z rosnącymi odstępami, jest przycisk „Ponów”.
  • Zaproszenia do organizacji po loginie przez Invitations API.

GitLab CE (self-hosted)

  • Własna instancja GitLab uczelni: adres i grupa ustawiane w tokenie; kursy i studenci to projekty tej grupy.
  • Prywatny osobisty projekt dla każdego studenta z rolą Developer.
  • Webhook na każdy osobisty projekt z sekretnym tokenem; konfiguracja jest weryfikowana przy każdym przebiegu, aby stary sekret nie pozostał.
  • Konfiguracja CI osobistego projektu przypięta do centralnego repozytorium testów: student nie może jej zmienić, granica ściślejsza niż na GitHubie.
  • Forki wyłączone; merge request z forka nie jest przyjmowany jako oddanie.
  • Odczyt testów centralnych przez członkostwo Reporter bez uprawnień do zapisu.
  • Przy tworzeniu projektu sprawdzany jest działający runner; zawieszony pipeline nie blokuje sprawdzania w nieskończoność, limit czasu jest konfigurowalny.
  • Przełączenie wersji testów centralnych dla kursu bez merge requesta.
  • Wspólny realm Keycloak dla systemu i GitLaba: jedno hasło do logowania w obu.
  • Wymagania dla runnera udokumentowane: docker executor, limity zasobów, limity czasu, izolacja sieciowa, automatyczne anulowanie zbędnych pipeline'ów.

Co zapewnia uczelnia

  • Organizacja na GitHubie lub grupa we własnym GitLabie CE.
  • Konto bota i tokeny o minimalnych uprawnieniach zarejestrowane w systemie.
  • Dla GitLaba runner na docker executorze; dla GitHuba minuty Actions lub własny runner.
  • Publiczny adres dla webhooków; bez niego przejmuje zapasowe odpytywanie.

Dla studenta

Przydzielone zadania

  • Karty zadań: kurs, zadanie, termin, status pracy; widoczne tylko zadania własnej grupy.
  • Wyszukiwanie po zadaniach i filtr według statusu.
  • Sortowanie według terminu, najbliższe najpierw, z uwzględnieniem indywidualnego przedłużenia.
  • Wskaźnik nieprzeczytanej informacji zwrotnej na karcie zadania.
  • Odznaka „repozytorium w przygotowaniu”, gdy osobiste repozytorium jest tworzone, i oznaczenie „zamknięte” na zamkniętych zadaniach.
  • Strona zadania: instrukcja, przewodnik i szablon raportu z pełnym formatowaniem (nagłówki, listy, bloki kodu).
  • Link do osobistego repozytorium, gdy tylko jest gotowe.
  • Publiczna rubryka z kryteriami i punktami: za co są punkty, widać przed rozpoczęciem pracy.
  • Osobisty numer wariantu i jego treść.
  • Termin oddania z uwzględnieniem indywidualnego przedłużenia.
  • Czytelny komunikat zamiast pustej strony, gdy treść zadania jest chwilowo niedostępna.

Oddawanie prac

  • Przyciski „Wyślij do sprawdzenia” i „Wyślij ponownie” po poprawkach; gdy oddanie jest niemożliwe, przycisk wyjaśnia dlaczego.
  • Oddanie rejestruje się automatycznie ze zdarzenia w systemie hostingu kodu, bez ręcznych kroków.
  • Praca po terminie jest przyjmowana i oznaczana „spóźniona”; nie ma automatycznych kar, decyzja należy do wykładowcy.
  • Poprawki bez limitu prób, dopóki wykładowca nie zatwierdzi oceny.
  • Do pull requesta trafia tylko neutralne powiadomienie z linkiem do systemu: bez punktów i treści informacji zwrotnej.
  • Ręczne powiązanie pull requesta jako ścieżka awaryjna.
  • Raport według sekcji rubryki bezpośrednio w systemie, na osobnej zakładce strony pracy.
  • Szkic raportu zapisuje się automatycznie podczas pisania.
  • Podgląd sekcji w sformatowanej postaci i powrót do edycji.
  • Załączniki do raportu: obrazy i pliki tekstowe, do 5 MB na plik i 25 MB łącznie.
  • Oznaczenie „sekcja bez zmian” dla sekcji, które nie wymagały poprawek.
  • Oddanie raportu z potwierdzeniem; odznaki „szkic” i „oddany” z datą.
  • Automatyczne sprawdzenie czeka na oddanie raportu i nie startuje wcześniej.

Status sprawdzania i informacja zwrotna

  • Czytelne statusy pracy: wysłana, sprawdzana, sprawdzona, do poprawy, oceniona.
  • Oś czasu kroków sprawdzania z datami wysłania i wystawienia oceny.
  • Blok „co poprawić” na górze strony, gdy praca wraca do poprawy.
  • Oznaczenie „oddano po terminie” na stronie pracy.
  • Link do kodu pracy i historii zmian.
  • Punkty za każde kryterium rubryki i komentarz wykładowcy; pola wewnętrzne rubryki nie są pokazywane studentowi.
  • Wyniki automatycznej analizy nie są pokazywane studentowi: to wewnętrzne narzędzie wykładowcy.
  • System pamięta, że informacja zwrotna została otwarta, i zdejmuje wskaźnik nieprzeczytania.
  • Po zwrocie pracy do poprawy ma ona własny termin ponownego oddania, widoczny na stronie pracy.

Oceny

  • Tabela ocen: kurs, zadanie, punkty, maksimum, data.
  • Podsumowanie: średni procent, ile ocenionych z przydzielonych, najlepszy wynik.
  • Z wiersza tabeli do szczegółowej informacji zwrotnej o pracy.
  • Powiadomienia o informacji zwrotnej wewnątrz systemu, bez wysyłek e-mail.

Dla wykładowcy

Kursy

  • Lista kursów, do których wykładowca jest przypisany: nazwa, repozytorium, liczba zadań, bieżąca wersja, status (szkic, opublikowany, archiwum).
  • Wyszukiwanie po nazwie i filtr według statusu kursu.
  • Karta kursu: repozytorium, wersja, liczba zadań, lista wykładowców, ikona systemu hostingu kodu.
  • Kontrola struktury kursu przed publikacją: raport znalezionych zadań i błędów.
  • Publikacja wersji kursu: zadania i rubryki ładują się do systemu i stają się dostępne do przydzielania.
  • Wskaźnik „są nieopublikowane zmiany” względem bieżącej wersji.
  • Tworzenie nowego zadania jednym formularzem: system zakłada szkielet z wymaganymi plikami i otwiera pull request.
  • Lista oczekujących zadań, utworzonych, ale jeszcze niezmergowanych, z linkami do ich pull requestów.
  • Edycja danych zadania: tytuł, kolejność na liście, archiwizacja.
  • Podgląd zadania w systemie: instrukcja, szablon raportu, rubryka, przykładowe rozwiązania.
  • Edycja plików tekstowych zadania w interfejsie; zmiana wychodzi jako pull request, nigdy bezpośrednio do kursu.
  • Baner z linkiem do otwartego pull requesta po każdej zmianie.
  • Asystent treści: z krótkiego opisu tematu powstaje szkic zadania z instrukcją, przewodnikiem i rubryką.
  • Asystent rubryki: kryteria i punkty proponowane na podstawie tekstu gotowego zadania.
  • Szkic asystenta nigdy nie publikuje się sam: przychodzi jako propozycja, którą wykładowca poprawia i akceptuje.
  • Konfiguracja automatycznych testów kursu: wybór z gotowych szablonów, podgląd, zastosowanie przez pull request.
  • Widać, które szablony są już zastosowane i ile własnych plików testów dodano ponad nie.

Zadania i rubryki

  • Rubryka zadania: kryteria z nazwą, opisem, maksymalną liczbą punktów i rodzajem sprawdzenia, automatycznym lub ręcznym.
  • Suma punktów rubryki jest liczona i sprawdzana przy publikacji.
  • Prywatne wskazówki dla sprawdzającego widzi tylko wykładowca; nie trafiają do studenta.
  • Punkty bonusowe za zadanie jako osobny blok.
  • Indywidualne warianty zadania.
  • Publiczna część rubryki, kryteria i wagi, jest widoczna dla studenta.
  • Rubryka jest utrwalana snapshotem w chwili przydzielenia: późniejsze zmiany kursu nie zmieniają już wydanego zadania.

Przydziały

  • Przydzielanie zadań grupie jednym formularzem-harmonogramem: kurs, zestaw zadań, grupa, własny termin dla każdego zadania.
  • Przydzielać można tylko opublikowane kursy i tylko grupom przypisanym do wykładowcy.
  • Skład uczestników jest ustalany w chwili przydzielenia: przeniesienie studenta do innej grupy nie psuje historii ani oddanych prac.
  • Każdemu uczestnikowi automatycznie powstaje osobiste repozytorium ze startowym szkieletem; student widzi zadanie od razu, repozytorium po przygotowaniu.
  • Gotowość repozytorium per student: gotowe, w przygotowaniu, błąd; ponowna próba dla tych, u których się nie udało.
  • Dosynchronizowanie uczestników: dodanie tych, którzy dołączyli do grupy po starcie.
  • Indywidualne przedłużenie terminu konkretnemu studentowi z oznaczeniem w tabeli uczestników.
  • Zmiana terminu oddania od razu dla całej grupy.
  • Zamknięcie przydziału jawną akcją z listy.
  • Usunięcie omyłkowo utworzonego przydziału, dopóki nikt nie oddał pracy.
  • Każda zmiana przydziału trafia do dziennika: kto, co i kiedy zmienił.
  • Tabela przydziałów: kurs, zadanie, grupa, termin, uczestnicy, oddane, czekające na sprawdzenie, status; filtry według kursu, grupy i statusu.
  • Zbiorcze liczniki gotowości repozytoriów i przejście do listy prac studentów.
  • Model sprawdzania przez asystenta wybiera się dla strumienia lub pojedynczego zadania; bez wyboru działa model domyślny.
  • Macierz postępów strumienia: studenci i zadania ze statusami, podsumowanie dla każdego studenta, eksport do CSV.

Kolejka sprawdzania

  • Kolejka pracy dla zadania: student, link do pracy, status, wynik automatycznego sprawdzenia, ocena, data aktualizacji.
  • Licznik prac czekających na decyzję wykładowcy i filtr według statusu.
  • Oznaczenie „spóźniona” w kolejce.
  • Wykładowca widzi tylko prace przypisanych do niego grup.
  • Wspólna kolejka „Sprawdzanie”: wszystkie oddane prace ze wszystkich zadań wykładowcy w jednej liście, z filtrami i licznikami.

Analiza asystenta

  • Automatyczna analiza startuje sama, z opóźnieniem, aby nie uruchamiać się przy każdej drobnej zmianie.
  • Odznaka „sprawdzenie odłożone do …” z przyciskiem natychmiastowego uruchomienia.
  • Statusy analizy: w kolejce, w toku, gotowe, wymaga uwagi, błąd.
  • Wstępna suma punktów automatycznych bezpośrednio w kolejce.
  • Nieudana analiza jest pokazywana z przyczyną i przyciskiem ponownego uruchomienia.
  • Oznaczenie „wymaga ręcznej uwagi” na wynikach, które nie przeszły filtra jakości.
  • Podpowiedzi dla każdego kryterium: proponowane punkty, poziom pewności, komentarz i odniesienia do dowodów w kodzie.
  • Kryteria o niskiej pewności są podświetlane, aby wykładowca spojrzał na nie najpierw.
  • Przycisk „wstaw punkty asystenta” wypełnia wszystkie pola naraz, pozostawiając je edytowalne.
  • Komentarz ukryty przez filtr bezpieczeństwa pokazuje przyczynę: zgodność ze wzorcem lub z instrukcją dla sprawdzającego oraz sam fragment.
  • Tekst ustrukturyzowanego raportu studenta jest przekazywany asystentowi jako kontekst.
  • Wydatki na analizę są ograniczone dziennym budżetem na kurs; wykładowca może uruchomić sprawdzenie także ponad budżet.
  • Sprawdzenie przez asystenta można uruchomić ponownie także po gotowym wyniku, dopóki praca nie jest oceniona; obok wyniku widać model, który sprawdzał.

Ocenianie

  • Ekran oceniania: kryteria rubryki z polami punktów i kontrolą, że wynik nie przekracza maksimum.
  • Obok każdego kryterium zwijana sekcja raportu studenta z miniaturami załączników.
  • Komentarz tekstowy dla studenta.
  • Zatwierdzenie oceny końcowej: praca przechodzi w „oceniona”, do pull requesta trafia neutralne powiadomienie.
  • Zwrot pracy do poprawy z obowiązkowym komentarzem.
  • Korekta już zatwierdzonej oceny z obowiązkowym podaniem powodu.
  • Ponowne otwarcie ocenionej pracy do kolejnego sprawdzenia z obowiązkowym podaniem powodu.
  • Kto i kiedy zatwierdził lub zmienił ocenę, zapisuje się w dzienniku audytu.
  • Wynik końcowy i maksimum na ekranie po zatwierdzeniu.
  • Oznaczenie „oddano po terminie” można zdjąć lub przywrócić dla pojedynczej pracy z podaniem powodu.

Dla maintainera kursu

Kursy i repozytoria

  • Rejestracja kursu jednym formularzem: wybór tokenu (dostawca i organizacja pochodzą z niego), nazwa repozytorium, tytuł, opis; ostateczna nazwa z prefiksem widoczna przed zapisem.
  • Utworzenie prywatnego repozytorium kursu z początkowym commitem; ponowna rejestracja jest bezpieczna.
  • Token kursu jest opcjonalny: gdy pusty, używany jest token systemowy.
  • Wszystkie kursy na jednej stronie z wyszukiwaniem i filtrem według statusu.
  • Przypisanie wykładowcy dostępnych grup dydaktycznych: pola wyboru dla grup, „zaznacz wszystkie”, licznik przypisanych.
  • Wykładowców kursu przypisuje się i usuwa bezpośrednio w karcie kursu.

Przegląd i publikacja

  • Kolejka przeglądu: otwarte merge requesty ze wszystkich kursów (kurs, autor, numer, liczba plików, data) z wyszukiwaniem według kursu, autora i tytułu.
  • Etykieta „workflows” na żądaniach dotykających plików automatycznych testów.
  • Zatwierdzenie lub prośba o zmiany z komentarzem; liczniki zatwierdzeń i próśb o zmiany.
  • Scalenie przez system tylko po zatwierdzeniu albo przez osobę, która nie jest autorem.
  • Publikacja jest odrzucana, gdy do gałęzi głównej trafiły zmiany bez zatwierdzenia; bramka działa także tam, gdzie ochrona gałęzi jest niedostępna.
  • Kontrola strukturalna przy publikacji: instrukcja jest na miejscu, rubryka jest poprawna, suma punktów się zgadza, katalog prywatny nie jest kopiowany studentom.
  • Granica poufności na katalogu grading: rozwiązanie wzorcowe, wskazówki dla sprawdzającego i ukryte testy nigdy nie opuszczają repozytorium kursu.
  • Wersja kursu to tag git; zawartość pod tagiem jest niezmienna, już wydane przydziały się nie zmieniają.
  • Przeglądy i scalenia są zapisywane w dzienniku audytu.

Centralne testy CI

  • Jedno centralne repozytorium automatycznych testów na organizację; wdrożenie jednym kliknięciem, bezpieczne do powtórzenia.
  • Zestaw startowy siedmiu testów: wstępna kontrola oddania, lint struktury, testy dymne, wyszukiwanie wyciekłych sekretów, uszkodzone linki, lint treści, etykietowanie żądań.
  • Wyszukiwanie sekretów skanuje historię, a nie tylko bieżące pliki.
  • Karta stanu: skonfigurowano, wdrożono, bieżące wydanie, tagi pływające, otwarte żądania; diagnoza „czego brakuje” z linkiem do ustawień.
  • Podgląd plików testów i edycja przez merge request do gałęzi serwisowej; kolejka żądań centralnego repozytorium z tą samą bramką przeglądu.
  • Wydanie z wyborem poziomu (major, minor, patch): dokładny tag jest ustawiany, pływający przesuwa się automatycznie.
  • Macierz wersji według kursów: aktualne, przestarzałe, stary format, brak testów, błąd.
  • Migracja kursu do nowej wersji jednym kliknięciem: żądanie zmieniające tylko odwołania do wersji; dla GitLaba przełączenie bez żądania.
  • W repozytoriach kursów i studentów cienkie wstawki wskazujące na tag pływający: poprawki docierają bez commitów do każdego repozytorium.
  • Bez centralnego repozytorium działają wbudowane szablony; podgląd pokazuje, które są używane.
  • Rozdzielenie tokenów: jeden do edycji i wydań, drugi tylko do wdrożenia.
  • Wdrożenie, edycje, wydania i migracje są zapisywane w dzienniku audytu.

Ustawienia systemu

  • Jedna strona ustawień; tokeny i dostawcy wybierani z list, a nie wpisywani jako identyfikatory.
  • Domyślna rola nowych użytkowników; domyślna organizacja GitHub i grupa GitLab.
  • Prefiksy nazw repozytoriów kursów i osobistych repozytoriów studentów.
  • Systemowy token treści kursów z nadpisaniem dla pojedynczego kursu.
  • Opóźnienie przed automatycznym sprawdzeniem, dzienny budżet tokenów na kurs, model domyślny i model zapasowy, interwał zapasowego odpytywania oddań.
  • Bramka publikacji: obowiązkowe zatwierdzenie albo wyłączona dla wykładowcy pracującego samodzielnie.
  • Ustawienia testów centralnych: dostawca, nazwa repozytorium, tokeny; ścieżka konfiguracji CI dla osobistych projektów GitLab.
  • Ostrzeżenia o odwołaniach do usuniętych lub odwołanych tokenów bezpośrednio na stronie; każda zmiana trafia do audytu jako para „stare → nowe”.

Dla administratora

Użytkownicy

  • Lista: login, imię i nazwisko, e-mail, rola, grupy, status, data; wyszukiwanie, filtry według roli i statusu, sortowanie, stronicowanie.
  • Tworzenie użytkownika jednym formularzem: e-mail, login, imię i nazwisko, hasło, rola; konta GitHub i GitLab, numer indeksu.
  • Unikalność e-maila i loginu bez rozróżniania wielkości liter.
  • Masowy import z CSV: podgląd, podświetlenie błędnych wierszy, import tylko poprawnych, raport wiersz po wierszu; do 500 wierszy; ochrona przed wstrzyknięciem CSV; wiersz bez hasła tworzy użytkownika z zaproszeniem przez link.
  • Edycja: imię i nazwisko, login, e-mail, rola, konta w systemach kodu, numer indeksu; zmiana roli działa natychmiast.
  • Po jednym koncie na każdego dostawcę kodu: GitHub i GitLab jednocześnie.
  • Reset hasła: hasło tymczasowe pokazywane raz, zmiana przy następnym logowaniu obowiązkowa.
  • Dezaktywacja z wyjaśnieniem skutków zamiast usuwania; dane pozostają; reaktywacja tym samym przyciskiem.
  • Ochrona ostatniego i początkowego administratora przed dezaktywacją i degradacją.
  • Zdezaktywowany student: historia pozostaje, nie trafia do nowych przydziałów, już oddane prace można ocenić.
  • Dostęp nadaje się linkiem zaproszenia z e-maila zamiast hasła tymczasowego; w karcie użytkownika widoczny jest status zaproszenia.

Grupy

  • Lista grup: nazwa, typ, liczba członków, właściciel; wyszukiwanie i filtr według typu.
  • Tworzenie: unikalna nazwa i typ, dydaktyczna lub dowolna; student należy najwyżej do jednej grupy dydaktycznej.
  • Edycja nazwy i typu na stronie grupy z ostrzeżeniem przy zmianie typu.
  • Archiwizacja zamiast usuwania z pokazaniem liczby członków; przywrócenie jednym przyciskiem.
  • Członkowie: dodawanie z wyszukiwaniem, usuwanie z potwierdzeniem, wyznaczanie właściciela; właściciel sam zarządza składem.
  • Zbiorcze dodawanie do 100 osób naraz z filtrem według roli i dwustopniowym potwierdzeniem.
  • Członków grupy dydaktycznej można podzielić na podgrupy; zadanie przydziela się całej grupie lub pojedynczej podgrupie z własnym terminem.

Tokeny systemów kodu i klucze modeli

  • Tokeny systemów kodu: GitHub lub GitLab, adres instancji self-hosted, organizacja lub grupa, notatka o uprawnieniach, data wygaśnięcia.
  • Przechowywanie wyłącznie w postaci zaszyfrowanej, na listach maskowane; weryfikacja próbnym wywołaniem dostawcy, w tym dostępu do organizacji.
  • Kilka tokenów dla różnych organizacji; ostrzeżenie 14 dni przed wygaśnięciem.
  • Rotacja w miejscu bez ponownego wiązania kursów.
  • Odwołanie jako wyłącznik awaryjny: natychmiastowe i nieodwracalne, z pokazaniem dotkniętych kursów i ustawień; wszystko odwołane jest wszędzie odrzucane jawnym błędem.
  • Usunięcie tylko po odwołaniu i tylko gdy token nie jest nigdzie używany.
  • Klucze modeli: dostawca (w tym OpenRouter z modelem zapasowym i polityką przetwarzania danych), model domyślny, limit, termin; szyfrowanie, maskowanie, weryfikacja próbnym wywołaniem.
  • Te same zasady rotacji, odwołania i usuwania dla kluczy modeli; odwołany klucz domyślny czyni sprawdzanie jawnie niedziałającym zamiast wyłączać je po cichu.
  • Przy pierwszym uruchomieniu system sam tworzy lokalną zaślepkę klucza: potok sprawdzania działa bez zewnętrznego modelu.
  • Tworzenie, rotacja, odwołanie i usunięcie są zapisywane w dzienniku audytu.

Dziennik audytu

  • Dziennik: czas, akcja, kto, na czym, szczegóły; tylko dla administratora.
  • Filtry według akcji, aktora, celu i dat; stronicowanie, najnowsze na górze.
  • Tylko dopisywanie: wpisów nie można zmienić ani usunąć przez interfejs ani API.
  • Co trafia: logowania i nieudane próby z przyczyną i adresem; użytkownicy, ustawienia, tokeny; przydziały, oceny, autoring i przegląd, sprawdzenia, synchronizacja, oddania raportów.
  • Synchronizacja z systemem kodu zapisuje jedno zbiorcze zdarzenie z licznikami.

Synchronizacja z systemem kodu

  • Strona synchronizacji: wybór dostawcy i tokenu.
  • Raport rozbieżności: zgodne, są u nas i brak w systemie kodu, są tam i brak u nas.
  • Zastosowanie zaprasza brakujących do organizacji lub grupy; ponowne uruchomienie jest bezpieczne; próbne uruchomienie bez zaproszeń.
  • Wynik z licznikami i statusem każdej operacji; synchronizacja jednokierunkowa, z systemu do hostingu kodu.

SSO / OIDC

  • Dostawcy logowania OIDC i LDAP: tworzenie, edycja, aktywacja i dezaktywacja bez usuwania konfiguracji.
  • OIDC: wystawca, client id i secret, scopes, nadpisania adresów, claim z rolami; sekrety przechowywane zaszyfrowane.
  • Przycisk „Test”: discovery, JWKS, token endpoint; dla LDAP próbne powiązanie.
  • Przyciski dostawców na stronie logowania pojawiają się zależnie od aktywności dostawcy.
  • Authorization Code z PKCE, state i nonce, pełna weryfikacja tokenu ID; tokeny dostawcy obsługiwane wyłącznie na serwerze.
  • Automatyczne powiązanie istniejącego użytkownika po potwierdzonym e-mailu; automatyczne utworzenie przy pierwszym logowaniu z rozwiązywaniem kolizji loginu.
  • Mapowanie ról z claimu grup; rola odświeżana przy każdym logowaniu; ochrona ostatniego administratora działa także tutaj.
  • Wymuszone SSO: logowanie hasłem odrzucane dla wszystkich poza administratorami.
  • Dostawca LDAP: adres, DN powiązania, baza i filtr wyszukiwania, mapowanie atrybutów, LDAPS domyślnie.
  • Automatyczne powiązanie konta w systemie kodu z claimu dostawcy.
  • Wspólny realm Keycloak dla systemu i GitLaba: jedno hasło do obu; skrypt migracji istniejących użytkowników do Keycloaka.

Integracje i eksploatacja

Moduł AI

  • Dostawca modelu ze strukturalnym wyjściem; lokalna zaślepka do rozwoju; bez klucza potok działa w trybie ręcznego sprawdzania.
  • Model tylko zwraca analizę według zadanego schematu i nie wykonuje kodu; wykonanie tylko w CI bez sekretów systemu; klucze modeli są przechowywane na serwerze w postaci zaszyfrowanej i nie trafiają do przeglądarki.
  • Filtr wyjścia: zbieżności informacji zwrotnej z rozwiązaniem wzorcowym lub wskazówkami są wycinane, a sprawdzenie oznaczane „wymaga uwagi”.
  • Komentarz do kryterium ograniczony długością; swobodny tekst modelu nie jest publikowany.
  • Bramka CI: przy czerwonym automatycznym teście model się nie uruchamia; brak uprawnień tokenu to jawny błąd, a nie zielone przejście.
  • Opóźniony start, dzienny budżet, ponowienia z rosnącymi odstępami; po wyczerpaniu prób praca idzie do ręcznego sprawdzenia, potok się nie zatrzymuje.

Wdrożenie i eksploatacja

  • Docker Compose: API, worker, frontend, PostgreSQL; migracje stosowane automatycznie przy starcie; profil z Keycloakiem i OpenLDAP.
  • Kontrole gotowości i endpoint zdrowia; metryki Prometheus dla API i workera.
  • Worker to osobny proces tej samej bazy kodu: kolejka w PostgreSQL bez brokera, ponowienia, zadania okresowe.
  • Zapasowe odpytywanie otwartych merge requestów jako zabezpieczenie przy utracie webhooka lub braku publicznego adresu.
  • Obrazy dwuetapowe, procesy bez roota; konfiguracja przez zmienne środowiskowe; sekrety według profili.
  • Skrypt weryfikacji z profilami local, stand, prod: pytest, testy jednostkowe frontendu, E2E, przebieg SSO, przebieg na żywo z systemem kodu, testy dymne produkcji.

Bezpieczeństwo

  • Hasła Argon2; krótki token dostępu i token odświeżania z rotacją; ciasteczka HttpOnly; wylogowanie unieważnia sesję.
  • Limity prób logowania według adresu i e-maila; zaufanie do X-Forwarded-For tylko z wymienionych podsieci.
  • Nagłówki bezpieczeństwa w każdej odpowiedzi: nosniff, zakaz ramek, Referrer-Policy, CSP; HSTS na produkcji; CORS według listy.
  • Webhooki: HMAC-SHA256 dla GitHuba, sekretny token dla GitLaba, porównanie w stałym czasie, odrzucenie przed parsowaniem treści.
  • Wszystkie sekrety w bazie zaszyfrowane: tokeny systemów kodu, klucze modeli, client secret, hasło LDAP.
  • Do systemu kodu trafia tylko login: ani imię i nazwisko, ani e-mail, ani oceny.
  • Izolacja studentów: prywatne osobiste repozytoria, cudze prace niewidoczne; prywatna treść kursu nigdy nie jest kopiowana studentowi.
  • Brak twardego usuwania; dziennik audytu tylko dopisywany.
  • Kontenery bez roota; statyczna analiza bezpieczeństwa i audyt zależności przed każdym commitem.

Zobacz na żywo

Napiszcie do nas, pokażemy demo na waszym kursie.

Skontaktuj się z nami