SE - Sklady - vytvoření zásilky padá s konkrétním příjemcem #104
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: Disassembler/Spotter-VM#104
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?
jse zalogovaný jako Admin User
na stránce
https://dasm.dasm.cz:8443/eden/inv/send/create
jsem vytvořil fiktivní zásilku.
pokud jsem přidal do příjemce osobu Jiří Podhorecký, tak to při uložení vyrobilo ticket
https://dasm.dasm.cz:8443/eden/admin/ticket/eden/77.87.240.4.2017-10-07.01-32-33.0c0f69be-2f63-4afd-8ef1-62f036728e9d
jméno příjemce není vidět, je tam jen číslo 2
i opětovné pokusy k otevření padají do ticketu.
když jsem vytvořil jinou zásilku s jinou osobou jako příjemcem, tak se to uložilo a jméno příjemce je vidět v tabulce.
pokud by problém přímo souvisel jen s uživatelem Jiří Podhorecký tak je otázka, zda to nějak nesouvisí s právy tohoto uživatele (?)
Vytvořeno PR #1466. Není přímo related k tomuto issue, ale je related k vytváření skladišť.
Prosím o kontrolu, zda se výše uvedené chování stále projevuje. Nebyl jsem schopný jej replikovat. Je možné, že bylo v některém z commitů již opraveno, protože reprezentace dat se v poslední době řešili docela hojně.
assigned to @Disassembler
Zkusil jsem znovu zadat novou zásilku bez REQ čísla.
Odesilatele jsem zadal Jiří Podhorecký (aktuálně zalogovaný však Admin User)
Adresát jsem zadal původně Honza Pacient.
Uložil
Tento záznam se uložil OK bez chybových situací.
Vstoupil jsem znovu do tohoto záznamu (modrým tlačítkem na úpravu) a doplnil náhodné REQ číslo.
Změnil jsem odesílatele na Admin User a adresáta Jiří Podhorecký (s nápomocnou kontextovou nabídkou jména)
Po uložení to zbuchlo.
Ale záznam se uložil. Ve výpisu to vypadá dost podobně, jako dřív.
Zde spekuluji, zda tu není nějaký zmatek ve výběru osob.
Vysvětlím:
Moje výběry osob jsou v rámci tohoto testu zcela náhodné. Což fakticky znamená, že ve formuláři vybírám náhodnou Facility odkud a kam a pak náhodného člověka, který je fakticky přiřazen k úplně jiné Facility...
To je trochu mindfuck, protože v realitě asi nedává smysl vybírat zcela libovolného člověka odkudkoliv, byť patří pod jednu střechovou organizaci.
Přinejmenším je to velmi málo běžné, aby zásilka z Bruntálu byla odesílaná člověkem, který je profesně zařazen v Ústí nad Labem a posílá to do Facility Beroun člověku, který je profesně zařazen do Facility v Brně. Ledaže by to bylo hodně zmáknuté logisticky...(?) No, nevim.
Takovou situaci formulář dovoluje a to mne trochu znepokojuje.
OK, po šesti hodinách se mi konečně podařilo replikovat konkrétní situaci, kdy k chybě dochází.
Uživatel musí mít ve jméně diakritiku a zároveň musí mít vyplněný telefonický kontakt. Pokud jedno nebo druhé není splněno, k chybě nedojde. Ještě, že máte takové hezky testovací jméno, u mě by to nefungovalo. Teď se přemístím domů a vytvořím issue nebo rovnou PR.
Co se týče výběru lidí, asi bych do kódu zbytečné restrikce nezatahoval. Spolupracoval jsem s firmou, která vozila zboží z centrálního skladu v Praze do skladu v Hradci Králové. Zásobovací systém měli nastavený tak, že v odesílatel i příjemce byl ten samý člověk. Fyzicky ale seděl na židli v Brně. :)
wow, super. Ok, tak tedy do kódu s těmi lidmi vrtat nebudeme, stačí jen odhalit ty chyby.
Otevřeno issue #1479 v upstreamu.
added ~14 label
Opraveno v upstream commitu 2be8e11, změna reflektována u nás.
closed
changed milestone to %2