Seeder
Seeder copied to clipboard
Blacklisty, whitelisty
- [x] při výpisu blacklistů zobrazit jen prvních pár semínek a pak tlačítko zobrazit vše
- [x] zobrazit notifikaci v dashboardu, pokud se změní nějaký blacklist nebo whitelist (https://webarchiv.cz/seeder/source/dump)
ok, notifikace budou trochu slozitejsi
ty notifikace by mohli být jen něco ve smyslu, pokud je datum změny novější než datum, kdy sis to naposledy otevřel, tak se zobrazí nějaká hláška. Nemusí to být facebook realtime styl
Pripadne pri zmene moze pristat tiez email technickemu spravcovi...
Also, nevim co je whitelist, jestli tim myslis dump tak to je temer nemozne trackovat.
whitelist aka dump můžeš z těch notifikacích vynechat, tam to budeme muset do budoucna vymyslet nějak jinak, protože ten se bude měnit denně...
Ahoj, toz dostal som sa k praci s tym a je to fakt na palicu. Potreboval by som vyexportit semienka pre whitelist a blacklist:
-
[x] ako ciste txt, idealne na samostatnom okne, kde sa to da oznacit CTRL A a dalej s tym pracovat
-
[x] mat to cez api
-
[x] vidiet historiu zmien a zasahy jednotlivy uzivatelov (je tam tlacitko history, ale nefunguje mi)
@Visgean bolo by fajn zalozku "Generovat Whitelist" preradit z out of topic sekce ala about, napoveda apod do hlavny sekce, nad Blacklisty, ako "Whitelist".
Zaroven pri reorganizaci panelu, by mozno bolo fajn pre technickecho spravcu zgrupit jednotlive zalozky do vlastnej sekcie (podobne ako about), staci oddelitciarou napr, tj: Sklizne, Whitelist a Blacklist.
jen dodám, že historie u blacklistů jde vidět
@kvasnicaj @JanMeritus K tem notifikacim, nestacil by treba jenom cas od posledni zmeny?
Rozumim, ze potom by si spravce musi pamatovat ten cas od posledni zmeny, kdyz to kontroluje, ale minimalne by slo rychle poznat, jestli posledni zmena byla pred nekolika dny nebo minutami. Mohl bych tam pridat treba rozliseni barev, e.g. zelena=dnes, modra=do tydne, cervena=vic jak tyden, nebo neco podobneho.
Kdybyste fakt chteli notifikace, ze by se treba neco zobrazilo na dashboardu nebo by byly badges u jednotlivych polozek v navbaru, tak by to taky slo, budto nejakym frameworkem (e.g. https://github.com/django-notifications/django-notifications) nebo bych si neco napsal sam, ale chvili by to urcite trvalo a chtelo by to asi i jine vyuziti nez jenom pro blacklisty.
last update je dobrý nápad, to bych tam určitě nechal :) každopádně problém je, že technici nepracují se seedrem denně, takže tu změnu nezaznamenají. Ono to asi i platí pro ten dashboard. Nebylo by nejjednodušší řešení, kdyby to po editaci blacklistu prostě poslalo notifikační email?
edit: ještě doplním, že ty změny těch blacklistů nejsou nějak časté. Je jich do desítky ročně, takže pokud jsou ty notifikace pracné, tak je to zbytečné.
Ok, ten email by určitě šel. Na které emaily by se to teda mělo odeslat?
V base.py#46 je jaky admin nastavený jenom @Visgean, coz nevim, jestli je nejak upravene v produkcnim local_settings.py
nebo ne, pripadne jestli tam je nejaky dalsi seznam emailu spravcu.
Nebo proste vsem "staff" uzivatelum?
Totok. Nakoniec pre nas by malo byt primarne API, ktore posle JSON, v ktorom bude pole lastChanged. Z nasej strany by bol skript ktory by to cucal, napr, vzdy pred polnocou a zmenil by listy, ak by sa to lisilo od polednych udajov, ktore dostal den predtym.
Zaroven mozno upresnenie (do buducna by bolo zaujimave mat moznost mat testovaci whit a black, ktory by bol aplikovany na testovaci WB/pyWB)
@Fasand dej to na ten email v tom base.py, my si to když tak upravíme v local_settings.py, jestli to tam teď nemáme. Předpokládám, že tam těch emailů může být více.
@JanMeritus to lastchanged pole tam ani není potřeba ne? Stejně se to bude přepisovat celé? Každopádně už teď tam můžeš mít blacklistů, kolik chceš, protože ty si definujeme sami. A testovací Seeder ma testovací whitelist, protože využívá testovací DB :)
@kvasnicaj Datasety nj, su na prednaske, cajk. Kazdopadne, myslim ze je zbytocne prepisovat listy, pokial tam nie je zmena. Samozrejme mozme tuto funkcionalitu si urobit sami na strane BE (napr cez hashe) - ale myslim ze nie je na nasej strane aby sme si viedli kedy sa data menili.
@JanMeritus Pridal jsem tam to posilani na ADMINS emaily, prijde jednoduchy email "New Blacklist / Blacklist Updated" a v body je nazev. Chces k tomu i to api nebo bude stacit email?
@Fasand a jinak ty blacklisty jsou dostupné přes API?
Tak mažu, pridal jsem tam api pro Blacklisty:
/seeder/api/blacklist/
: seznam se vsim vsudy
/seeder/api/blacklist/{pk}
: konkretni blacklist
/seeder/api/blacklist/lastchanged/
: posledni zmena jakehokoli blacklistu, format {"lastChanged": "2019-07-08T09:56:21.955846Z"}
PR https://github.com/WebarchivCZ/Seeder/pull/509
QA
@habetpet prosim overit dostupnost vsech blacklistu a overit jestli takto neni dostupny i "whitelist"
@habetpet prosim doo overit dostupnost
@Fasand jsou takto dostupne i whitelisty? (FYI @habetpet , prosim prubezne zadokumentovat API rozhrani)
Whitelist (seed dump) je nyní dostupný jen přes /seeder/source/dump/
, ale můžu přidat jako JSON api na /seeder/api/whitelist/
.
Jak na to koukám, tak je veřejně dostupný bez přihlášení – to tak má být nebo rozhodně ne? Vypisují se tam jen veřejná semínka, ale i tak mi to přijde takové divné.
Potvrzení: změna endpointu na /seeder/api/whitelist/
, vrátí list(str)
v JSONu, veřejně dostupný bez API autorizace
Pozn. pro mě: myšleno jako TODO, ještě to tak není, už jsem to jednou pochopil blbě a zapomněl na issue :)
připomínám @Fasand :)
Přidávám upřesnění, protože některé naše aplikace a workflows používají /seeder/source/dump
, je potřeba ho zachovat, tedy jen případně vytvořit nový, nikoly přesunout komplet.
Měl jsem teď čas pročíst celé vlákno, tak tady shrnu přesné aktuální požadavky, ať je v tom pořádek a můžeme to konečně uzavřít.
- Endpoint
/seeder/source/dump
musí zůstat a je v pořádku, že je přístupný veřejně. - Měl by vzniknout nový endpoint
/seeder/api/whitelist
, který bude vracet data jako JSON, což bude konzistentní s chováním blacklistů. Datum změny není potřeba. - Views pro blacklisty jsou za mě OK a nepotřebují zatím další zásahy.
- Whitelist nemá vlastní view a asi ani nepotřebuje. Pokud by jsme našli odůvodnění proč ho mít, tak to otevřeme jako vlastní issue.
Mělo by to odpovídat tomu, jak jsme byli domluvení. Až bude vše hotovo a ověřím že je api funkční, tak toto issue uzavřu. V případě dalších opžadavků by bylo lepší začít nové vlákno.