SE - Zaměstnanci - import gender #22
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#22
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
při importu zaměstnanců neprochází parrametr gender.
v překladu jsem použil překlad na Muž, žena,
ve formuláři je v nabídce Muž, žena
ale když tento parametr dám do importního template, tak neprojde,
vznikne Errors:
gender: Value not allowed
potřebuju zjistit, jaké hodnoty má mít sloupec Sex.
Přiložte mi prosím nějaká importní data v XLS, abych si to nasimuloval. Stačí třeba jen tři řádky. Mám takový nepříjemný pocit, že platné hodnoty jsou
2pro ženu a3pro muže, ale raději to otestuju.BTW přímý import Excelové tabulky z MS Excelu do Sahany vykazuje problémy.
Takže když tuto tabulku uploadnu na Google drive, otevřu v aplikaci Tabulky a vyexportuju do XLSX, tak pak to znovu naimportuju ok.
Imho tenhle problém na Sahaně hlásili, takže o tom, vědí.
8_Stát_HZS_ČR.xlsx
Tohle bude ještě veselé.
settings.hrm.staff_label = "Contacts", což u nás je, mění to nejen název položky v menu, ale i chování. Protože v template nemáme doprogramovaný patřičný handler, vyhazuje to validační chybutype: Value not allowed.settings.hrm.staff_labelna výchozí hodnotu, import stejně selže s tím, že jsou vyžadována čísla ve správném formátu, tj. mezinárodním a žehrm_human_resource: department_id: value(s) required, což vypadá, že departmenty musí být již dopředu vytvořeny předtím než se do nich importují zaměstnanci.Zkusím najít nejméně bolestivou cestu vedoucí k úspěšnému importu.
mentioned in commit
85944f3bd7No. Tak je to ještě trochu jinak. On vám tam nějaký dobrák schoval sloupce, takže ve sloupci AE máte department ještě jednou, tentokrát s prázdnou hodnotou. Sahana při importu bere pouze první sloupec s daným jménem, což je zrovna tenhle.
Takže
ad 2) Prozatím vyřešeno commitem
85944f3bu nás a otevřením issue #1385 v upstreamu.ad 3) Telefonní čísla snad taktéž vyřešena v commitu
85944f3bnastavením výchozí mezinárodní předvolby. Departmenty ani organizace dopředu existovat nemusí.a nově, 4) Aby to nebylo tak jednoduché, tak maximální délka názvu departmentu je v tuto chvíli 64 znaků, což hravě překračujete. Zmínil jsem to také v #1385 přímo u zdroje, tak uvidíme.
Aha!
tak to s tím schovaným Departmentem je určitě moje vina, vzniklo to jistě tak, že jsem použil šablonu a pak pro pracovní účely jsem sloupce duplikoval.
Schovávám některé sloupce abych si zjednodušil phled na tabulku. v importu to nevadí.
Co se týče telefonních čísel - Ok, jsem schopen svoje templaty doplnit a dávat předvolbu 420 ... akorát mi dost sere Excel když dávám na začátek + .. on to chápe to jako matematický výraz. Nastavení typu buňky to moc nevylepšuje.
Mě je celkem jasné, čí je to vina, akorát jsem nechtěl být zbytečně drzý, dokud platíte :)
Telefonní čísla už by teď Sahana měla sežrat i bez předvolby. Pokud byste chtěl i předvolbu, znak + tam být nemusí (alespoň Sahana to pochopí i bez něj). Pokud chcete i znak +, narvěte před něj apostrof (
') a Excel pochopí, že nemá dělat kalkulačku.ok... akorát praxe je trochu košatější..
V praxi je vidět hromada kontaktních XLS, které jsou vytvářeny včetně telefonů, ale nikdy to nemá jednotnou formu. Takže ani nelze plánovat, že Sahana bude mít univerzálně blbovzdorný importer dat a konkrétněji importer tlf. čísel. Nelze nikoho předem vyučovat, jak má ukládat Tlf čísla.. Teprve až by k importu do SE došlo, musí se data zkontrolovat a forma upravit. (jak sem to taky dělal, ale neměl jsem zcela pevné přesvědčení zda zapisovat předvolbu nebo nikoliv).
Mám kontakty, které jsou i včetně telefonních čísel do zahraničí a tam je to velké peklo... například telefony na konzuláty a velvyslanectví v kdejaké Africe.
Takže jestli mohu prosit, importer telefonních čísel by neměl být příliš omezující jen pro ČR. Budou čísla i ze zahraničí.
S těmi telefonními čísly to je v Sahaně ještě zajímavější v tom, že pokud ho nějaká osoba v záznamu má, tak se jí "teoreticky" dá poslat SMS z rozhraní sahany.(Ano, vím že to je o ústa, proto tato možnost bude pod kontrolou přístupových práv jednotlivých subjektů) A to číslo by tedy mělo být ve formě, aby to SMS gateway sežrala.
V tuhle chvíli by měl importer žrát všechny formáty, tj. jak s prefixem, tak i bez něj, mezery nemezery, pomlčky nepomlčky. Proto jsem psal, že teď už je na Vás, jak chcete aby vaše data vypadala.
Z toho, co čtu v kódu validátoru a messagingu, je Sahana sama schopna poznat, jestli se jedná o mezinárodní číslo a pokud ne, přilepí k němu výchozí prefix. Obecná rada tedy zní - místní čísla jakkoliv, zahraniční vždy s prefixem. Až se dostaneme k messagingu, můžeme to ověřit.
Takže. Z této odpovědi vyplývá, že pokud chceme použít
settings.hrm.staff_label = "Contacts", musíme v importovaném XLS mít navíc sloupecType, který může nabývat hodnotstaff,volunteernebomember. Potvrzuji, že takový import mi pak projde. Navíc mi přijde jako dobrý nápad mít jej pro úplnost i pokud bychom ono upravené nastavení nepoužili.Bohužel z té odpovědi také vyplývá, že nehodlají navýšit počet znaků pro department, takže se stávájícími dat narazíte na limit. Argument dlouhými nečitelnými tabulkami celkem dává smysl, protože o tomto problému jste se zmiňoval i Vy. Buď tedy názvy departmentů zkraťte pod 64 znaků anebo vytvoříme lokální patch pouze pro naši instanci Sahany, ve kterém tento limit zvedneme.
Co se týče komentáře, že jsou dlouhé názvy... ano.. mě taky dlouhé názvy těch subjektů komplikují život. A dalo by se s tím elegantně vypořádat tím, že právě z toho důvodu se v reálu používají jasné zkratky, které jsou v tom konkrétním vesmíru velmi zažité. (Ministerstvo zahraničních věcí = MZV)
Jsem pro, aby se v interface Sahany více používaly zkratky Organizací a dalších subjektů. (a sám to tak zkouším aplikovat v některých případech.
V default template Sahany (konkrétněji jak v tabulkových výpisech, tak v různých formulářích) se však tyto zkratky moc nepoužívají, což znamená že:
Můj laický návrh tedy je:
v DataTables bude nutno předělat template zobrazení výpisů tak, aby se lépe využily ACRONYMS ..tj zkratky
-- to všechno jsou návrhy, které se snadno řeknou... ale nevím, jaký by byl průběh této změny, aby se dobře promítl na celou Sahanu.
Netrvám na tom, aby se pole příliš prodlužoval nad 64 znaků,
Už dříve jsem se snažil upozornit Fran&Dominic, že některé sloupce mají divné názvy, duplicitní, nebo zas rozdílné názvy atd. A že to komplikuje život při importu. Zejména cyklickém export-importu. Je to nekonečný oser s přejmenováním sloupců.
Typicky sloupec Type je na více importních šablonách.... Ale pokaždé ten Type může mít jiné hodnoty! Navíc to nikde není pořádně zdokumentované... Takže BFU který nemůže vlézt do kódu a najít jaké jsou hodnoty očekávány pro Type, to nijak nezjistí. A když se pokouší o import, může to selhat pro úplnou hloupost.
Když jsem se to snažil naznačit, tak jsem dostal odpověď, že ať si templaty každej pošteluje jak chce, vždyť je to snadné.. A že se to nemá dělat na straně serveru, ale na straně XLS nebo CSV.
!!!
To já sice chápu, ale měli by si uvědomit, že když to takhle nekonzistentně JE, tak všichni, tj jak developeři, tak uživatelé s tím mají trvale problém. Stačilo by to jednou udělat pořádně a problém by navěky zmizel. Pak ať si to každej developer šteluje a mění nad rámec toho základního nastavení,
no.. takže pro nás asi úkolem je se zorientovat a malými krůčky se zatím adaptovat na tento "téměř dobrý" stav.
V tomto příspěvku Dominic vysvětlil, že platné hodnoty se dají celkem snadno vyčíst z XSLT, které v podstatě existují výhradně proto, aby definovaly povolené hodnoty a formáty. Nicméně chápu, že je to něco, co musí člověk napřed vědět, aby to mohl použít, což je pro náhodného kolemjdoucího nemyslitelné. Z jeho příspěvku ale také vyplývá, že ví, že absence dokumentace je problém a dokonce tam navrhuje řešení. Jen by jej ještě někdo musel implementovat. :)
Zobrazení DataTables se budu věnovat v issue #45, až se k němu dostanu. A na ty zkratky u Facilities a Offices teoreticky můžete otevřít enhancement issue nebo to připsat do zadávací dokumentace pro programátora.
closed
No, jestli se někdo pustí do výroby vysvětlivek k CSV, tak to bude velké blaho pro nás "ostatní"... Dominicovi se to snadno řekne, ale když ladím jeden import pořád dokola, stále nevím jakých hodnot má nabývat shelter_type_id aby to šlo importovat a hledám konkrétní soubor půl hodiny a dalších 10 minut se snažím ho rozluštit, tak si raději nechci představit, co znamená nesnadno.
changed milestone to %2