Fórum Pirátské strany

Ahoj, už jsem celkem naštvaný z toho, že máme bordel v kontaktech,

1) já si je uchovávám v gmailovém listu, abych mohl posílat e-maily (jinak na posílání e-mailům členům potřebuji speciálně generovaný symbol),
2) sign up form byl vystaven oprávněné kritice, protože je na gforms (byť nelze zanedbat, že aspoň funguje!),
3) informace o členech máme v google tabulce, vedoucí týmů je mají nakoleni někde náhodně,
4) administrativní odbor má data ve vlastní ad hoc databázi.

To má řadu nežádoucích důsledků:
1) lidé, kteří údaje potřebují, to mají těžké dostat se k aktuálním datům, chybí jemná správa oprávnění nakládat s daty,
2) údaje jsou rozfrcené na spoustě místech, což způsobuje duplicitní chyby,
3) údaje jsou hostovány na google, jehož smluvní podmínky se nelíbí některým členům,
4) chybí nám jednoduché a rychlé pozvánky na akce.

Navrhuji tedy nasadit vlastní systém, open source CiviCRM - používá ho mj. EFF - a to hostovaně za cenu cca 5000 Kč ročně. Důvodem hostovaného řešení je, že nechci zatěžovat náš technický odbor s novou službou.

Jakub.Michalek píše:Zatím ze všeho, co jsem našel, je tomu nejbližší CiviCRM

https://civicrm.org/ - open source aplikace postavená nad drupalem, která umí správu členů, příspěvky, posílání e-mailů, pokročilou správu skupin a zakládání akcí s účastí
dobré je, že to používá i politická strana (Strana zelených na Novém Zélandu, politická strana v Indii)

https://civihosting.com/shared-hosting/ - zde je nabídka hostingu, abychom to nemuseli nahazovat u nás a řešit neustálé útoky na naše servery, cena je 4500-6100 Kč za rok na údržbu a 500 Kč jednorázový poplatek za instalaci
http://demo.civihosting.com/ - zde bylo demo (než jsem zmáčkl červené tlačítko, u kterého bylo napsáno "Bacha, udělejte si zálohu" a od té doby to nefunguje)

Nicméně to vypadá, že ta novozélandská zelená strana nakonec přešla v listopadu 2016 z CiviCRM na NationBuilder, patrně s tím bylo dost sraní a Nationbuilder "prostě fungoval".

Jsou k tomu i dvě knihy, které popisují používání:
http://libgen.io/get/EA84160FACF760AA81 ... 013%29.pdf
http://libgen.io/get/109AA40C95AE621C3E ... 011%29.pdf

Nevím, jestli by nám to pomohlo. Každopádně nějaký elektronický nástroj na kampaň potřebujeme.

post65611.html#p65611

Rad pomuzu s implementaci.

Lukas.Novy píše:post65611.html#p65611

...neubehlo ani 7 let...

Andrej.Ramaseuski píše:

Lukas.Novy píše:post65611.html#p65611

...neubehlo ani 7 let...

Četl jsi to celé? Kdybych tehdy neudělal bezpečnostní chybu, kterou mi nikdo nepomohl nalézt a odstranit, tak to moje řešení běhalo dodnes. Ale třeba za dalších 7 let bude CiviCRM a možná i HELIOS.

Lukas.Novy píše:post65611.html#p65611

Rad pomuzu s implementaci.

Nevidím tam ani Czech Republic, natož pak tebe.
https://civicrm.org/partners-contributors

EDIT: a který balík bys doporučoval?
Download CiviCRM 4.6.28 for Drupal 7.x
Download CiviCRM 4.6.28 for Drupal 6.x
Download CiviCRM 4.6.28 for Joomla 2.5.x / 3.x
Download CiviCRM 4.6.28 for WordPress 3.x / 4.x

4.7.17 v dockeru s Drupal7/drush. Deploy a testovani pomoci Gitlab CI, nase verze by forkovala upstream pri kazdym submajor release, minor verze by se mergovali. Nase upravy by byly test-driven, tzn. nejdrive by existoval test popsany slovne, k nemu se v pripade, ze je uprava vybrana k nasazeni v nasi hlavni vetvi, naimplementuje automatizovany test spolecne s prislusnou funkcionalitou. Test failuje pro revize bez funkcionality (provadi se na predchozim release pri merge requestu funkcionality) a passuje pro verze s ni (provadi se pri kazdem merge requestu i pri deploy nasi verze). Ve vetsine pripadu by mel automatizovany proces namergovat upstream patche sam, pustit testy, deploynout na staging a zadat deployment request. Odpovedne osobe by pak stacilo projit checklist na stage a odsouhlasit deploy, vse ostatni by bylo automagicke. V pripade, ze neprojdou testy, rucne se projdou upstream zmeny a namerguji se jenom security related veci, pripadne faily testu je treba vyresit rucne i za cenu dropnuti nejake nasi non-security upravy, vysledna hotifx verze se deployne a zacne se pracovat na postupnym mergovani dalsich (non-security) zmen z upstream a pripadne dropnutych nasich uprav. Pri zmene submajor verze v upstream je treba nase zmeny forwardportovat a z toho nebyl hell, tak jsou veskere upravy v nasem strome reseny jakozto samostatne patchfiles, ktere se aplikuji pred spustenim testu, pri deploy apod. Pravdepodobne bych to resil pomoci drush-patchfile. Kazdy patch musi tez projit testy samostatne. Tim by mela byt zajistena bezpecnost, kompatibilita s upstream, udrzovanost a udrzitelnost nasich uprav, dostatecne popisna specifikace uprav, agilne pruzny vyvoj i vsechny dalsi goodies.

Jakub.Michalek píše: https://civicrm.org/ - open source aplikace postavená nad drupalem, která umí správu členů, příspěvky, posílání e-mailů, pokročilou správu skupin a zakládání akcí s účastí

Na zběžný pohled to vypadá hodně dobře a zabili bychom tím minimálně dvě mouchy jednou ranou (evidenci členů a plateb, rozesílání hromadných infomailů).
Předpokládám, že doimplementovat tam současný systém automatických upozorňování na splatnost příspěvků by nemusel být problém.
Nejvíc práce asi bude s oprávněními (tedy kdo může vidět/editovat jaké informace a kdo může provádět jaké akce).

A rozhodně by to mělo běžet na stranickém systému, už kvůli těm našim potřebám různých customizací.

Stranický systém to bude tak jako tak, je jen otázkou, kde bude hostován. Vzhledem k tomu, že když jsme naposledy měli Drupal, tak ho nikdo nedokázal nastavit, byl bych rád, kdyby to měl v rukách někdo, kdo tomu rozumí. Nákladově a z hlediska rychlosti zavedení IMHO nejlépe vychází hostovaná možnost, kde za bezpečnost zodpovídá dodavatel.

Jakub.Michalek píše:Stranický systém to bude tak jako tak, je jen otázkou, kde bude hostován. Vzhledem k tomu, že když jsme naposledy měli Drupal, tak ho nikdo nedokázal nastavit, byl bych rád, kdyby to měl v rukách někdo, kdo tomu rozumí. Nákladově a z hlediska rychlosti zavedení IMHO nejlépe vychází hostovaná možnost, kde za bezpečnost zodpovídá dodavatel.

Hlavně, abychom mohli mít vlastní zálohu dat, kdyby se to u nich posralo třeba.

Tak to je snad samozřejmost. Ale určitě ji nebude mít Lukáš Nový