Mało znane fakty: coś już jest zaimplementowane

Bazowa funkcjonalność istnieje już od PR #1015, ale na produkcji jej nie widać, bo… model CompletedCourses, o który się ona opiera, jest w produkcyjnej bazie pusty. Żeby przekonać się, jak miało to w zamyśle wyglądać, możemy w wersji deweloperskiej uruchomić SQL-owy INSERT dostępny na SKOSie (por. Łączenie się z serwerem bazy danych środowiska deweloperskiego), po czym dla niektórych użytkowników będzie wyświetlać się taki oto dodatkowy wiersz w dziale "Moje studia" podstrony "Moje konto":

Chcemy (znacznie) rozwinąć tę funkcjonalność, przy czym będzie się ona opierać między innymi również na modelu CompletedCourses, więc ww. INSERT będzie bardzo przydatny także przy dalszych pracach.

Co (z grubsza) chcemy osiągnąć

Po pierwsze, w wersji produkcyjnej muszą zacząć się pojawiać dane w modelu CompletedCourses, ale to nie jest kwestia związana z kodem aplikacji – z wyjątkiem tego, że REST API tego modelu było błędnie zaprojektowane; jest już na to poprawka i jeśli okaże się dobra, to w tej sprawie raczej nie mamy więcej do roboty.

Po drugie, chcemy jakoś zakodować wymagania zawarte w programach studiów, a przynajmniej ich istotną część. Implementujemy, przynajmniej na razie, tylko wymagania dotyczące ukończenia studiów, zakładając, że śledzenie zaliczania kolejnych semestrów jest dostatecznie proste dla człowieka.

Po trzecie, na podstawie danych z modelu oraz zakodowanych wymagań, chcemy prezentować informacje, które wymagania są już spełnione, a które nie, i ile jeszcze do tego brakuje.

Obecne prace są w branchu https://github.com/iiuni/projektzapisy/tree/create-my-studies-page. Poprzednie podejście do tematu w PR #1178 (którego dotyczy strona Wiki Plik z wymaganiami studiów wymagania.json) zostało wdrożone, ale chyba przedwcześnie – w pewnym momencie zaczęły pojawiać się nieoczywiste do zdiagnozowania wyjątki i m.in. dlatego zmiana została wycofana; tym niemniej niektóre pomysły być może można zaadaptować. "Stary" branch został odtworzony, więc w szczególności można go wycheckoutować, gdyby ktoś miał taką potrzebę.

Programy studiów i ich kodowanie

Większość programów studiów leży na https://ii.uni.wroc.pl/dla-studenta; widzimy od razu, że oprócz kierunku i toku studiów (np. informatyka licencjacka, inżynierska bądź II st.) mają one swoje wersje/warianty zależne od tego, kiedy dana osoba rozpoczęła (obecne) studia. W związku z tym, że na "starych" programach jest już bardzo mało osób, będziemy się na razie zajmować tylko programami dla zaczynających w 2019 lub później.

Ważne: efekty kształcenia (w wąskim sensie tego określenia) i znaczniki tematyczne ("tagi") to dwie różne rzeczy, przechowywane w bazie w dwóch różnych modelach (odp. courses.Effects i courses.Tag), a każdy przedmiot (CourseInformation) ma je określone niezależnie:

    tags = models.ManyToManyField(Tag, verbose_name="tagi", blank=True)
    effects = models.ManyToManyField(Effects, verbose_name="grupy efektów kształcenia", blank=True)

Oczywiście może się zdarzyć (i zdarza się) że jakiś przedmiot ma określone znaczniki, ale nie efekty, albo na odwrót, ale nie zastanawiamy się nad tym, jak odgadnąć jedne na podstawie drugich – o ile przynajmniej część takich luk powinna zostać w produkcyjnej bazie uzupełniona, to to znowu jest niezależne od nas. Oczywiście jeśli do testów brakuje nam np. znaczników przedmiotów, możemy je sobie w wersji deweloperskiej dodać w dowolny sposób. Nowe programy studiów używają (chyba) tylko znaczników, a nie efektów kształcenia.

Programy studiów chcemy zakodować w dokumentach JSON stworzonych w ten sposób, żeby oprócz tego, że będą stanowić dane wejściowe dla aplikacji, były też czytelne dla człowieka i np. w miarę łatwe do porównania z dokumentem PDF ze strony Instytutu, który kodują. W szczególności oznacza to, że nie powinny się tam pojawiać żadne identyfikatory obiektów, a tylko np. skróty znaczników itd.

Obecnie leżą one bezpośrednio w repozytorium (np. https://github.com/iiuni/projektzapisy/blob/create-my-studies-page/zapisy/apps/effects/inf1stlic.json), natomiast docelowo powinny trafić do bazy. Mamy już model Program, ale skoro programy mają swoje warianty, to będzie potrzebny jakiś nowy, o np. takich atrybutach:

• krótka i długa nazwa
• data rozpoczęcia studiów, od której obowiązuje; być może to jest wtórne względem (krótkiej) nazwy
• ForeignKey do Program
• JSON z wymaganiami (być może na początek tylko ścieżka do niego)
• URL do dokumentu ze strony Instytutu

Nie wszystkie wymagania przewidziane w programie studiów zdecydujemy się prezentować (nie wszystkie się w ogóle będzie dało w oparciu o dane gromadzone w SZ – np. lektoraty, WFy) i informacja o tym też się powinna w tych JSONach znajdować.

Być może przydałby się (nawet do wewnętrznego użytku) bardziej szczegółowy opis tych JSONów (i/lub schema do ich walidacji, ale to tak tylko "dla porządku", tj. nie planujemy wymiany tych dokumentów z żadnym innym serwisem), ale na razie go nie ma. Podstawowa idea jest taka, żeby wymagania do zaliczenia studiów znajdowały się na liście (pod kluczem "wymagania") w postaci obiektów; typowy taki obiekt może mieć klucze "liczba_ects", "liczba_przedmiotow", "typy_przedmiotow", "tagi_przedmiotow", na podstawie których oblicza się, czy wymaganie jest spełnione, czy nie (i ew. "jak bardzo"), klucz "nazwa" służyłby tylko do wyświetlania opisu danego wymagania.

Prezentacja wymagań

Poniższa makieta przygotowana przez @TWolczanski jest wystarczająco dobra, przynajmniej jeśli chodzi o pierwszą wersję strony, którą chciałybyśmy publicznie pokazać:

Warto zwrócić uwagę na "niezakodowane" wymagania, zgrupowane na końcu listy. Na potrzeby wersji mobilnej można zaimplementować (chyba niezbyt skomplikowanie) przełączanie się do takiego wariantu poniżej pewnego breakpointu.

Misc

Z "wysokopoziomowych" rzeczy do zrobienia jest m.in.

• uporządkowanie i zakodowanie kolejnych programów studiów
• przemyślenie sensowności wprowadzenia np. nowych typów przedmiotów (choćby praktyki zawodowe), jeśli miałoby to niskim kosztem pozwolić na zakodowanie pewnych wymagań dotąd "niekodowalnych" (a dla praktyk zawodowych przy okazji temat wiąże się, choć chyba dość luźno, z potrzebą uruchomienia ich oceny, tj. à la ocena zajęć)