Spotter-Cluster/Spotter-VM
2
0
Fork 0
Code Issues78 Pull Requests Actions Packages Projects Releases Wiki Activity

SE - Organisations - Resource type #27

New Issue
Closed
opened 2017-09-19 23:01:04 +02:00 by Podhorecky · 8 comments
Podhorecky commented 2017-09-19 23:01:04 +02:00 (Migrated from git.spotter.cz)

V Modulu Organisations je sekce Resources (Zdroje)
V importní šabloně pro toto mám vyplněný sloupec Resource Type

V rozhraní SE se nikde nedá předem definovat číselník Resource Type
importuji data a sloupec Resource Type se nenačte a v rozhraní se zobrazí jako pomlčka.

Když vstoupím do detailu a ručně přidám |Resource Type do pop-up okna, upraví se ta jedna položka.

Když znovu zkusím importovat template s vyplněnými daty, tak se stejně Resource Type nikde nevyužije.

Zároveň v tomto importu se neslučují duplicitní položky, takže po druhém importu je dvojnásobek databázových řádek.

Nedokážu posoudit, zda to je

  • věc nějaké konfigurace
  • SW chyba (asi ne, protože to nepadá)
  • nenaprogramované, tj že to někdo neudělal
V Modulu Organisations je sekce Resources (Zdroje) V importní šabloně pro toto mám vyplněný sloupec Resource Type V rozhraní SE se nikde nedá předem definovat číselník Resource Type importuji data a sloupec Resource Type se nenačte a v rozhraní se zobrazí jako pomlčka. Když vstoupím do detailu a ručně přidám |Resource Type do pop-up okna, upraví se ta jedna položka. Když znovu zkusím importovat template s vyplněnými daty, tak se stejně Resource Type nikde nevyužije. Zároveň v tomto importu se neslučují duplicitní položky, takže po druhém importu je dvojnásobek databázových řádek. Nedokážu posoudit, zda to je - věc nějaké konfigurace - SW chyba (asi ne, protože to nepadá) - nenaprogramované, tj že to někdo neudělal
Podhorecky commented 2017-09-20 00:03:12 +02:00 (Migrated from git.spotter.cz)

12_Defibrilatory_TLF_budky.xlsx

[12_Defibrilatory_TLF_budky.xlsx](/uploads/9f167c0d3f4cab53f2c84ac88b28322e/12_Defibrilatory_TLF_budky.xlsx)
Disassembler commented 2017-09-23 16:48:39 +02:00 (Migrated from git.spotter.cz)

Zpřístupnění číselníku Resource Type pushnuto jako PR #1386 do upstreamu. Na import samotný se jdu teď podívat.

Zpřístupnění číselníku *Resource Type* pushnuto jako PR [#1386](https://github.com/sahana/eden/pull/1386) do upstreamu. Na import samotný se jdu teď podívat.
Disassembler commented 2017-09-23 16:48:44 +02:00 (Migrated from git.spotter.cz)

added ~14 label

added ~14 label
Disassembler commented 2017-09-23 17:00:31 +02:00 (Migrated from git.spotter.cz)

Jo, tak s importem jste se zase vypekl sám. Sloupec se musí jmenovat Resource Type s velkým T.

Jo, tak s importem jste se zase vypekl sám. Sloupec se musí jmenovat *Resource Type* s velkým *T*.
Disassembler commented 2017-09-23 20:03:51 +02:00 (Migrated from git.spotter.cz)

Vyřešeno v upstream commitu c1c4878, změny reflektovány u nás.

Vyřešeno v upstream commitu [c1c4878](https://github.com/sahana/eden/commit/c1c4878734bf9b6e6dd5b8e2a88791db344512cd), změny reflektovány u nás.
Disassembler commented 2017-09-23 20:03:51 +02:00 (Migrated from git.spotter.cz)

closed

closed
Podhorecky commented 2017-09-23 20:50:24 +02:00 (Migrated from git.spotter.cz)

Díky moc za debatní kolečko..
Co se týče case-sensitive, tak ano jsem si toho vědom, ale nepozorností mi to někdy unikne. A pak to nejde importovat. :)
Co se týče nějaké té diskuse na GitHubu, tak určitě dobré brát v úvahu co říkají, říkají to vesměs jako nějakou praktickou zkušenost. Ale někdy z nich vidím evidentní nechuť that kostlivce ze skříně.

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:

  • se neušetří prostor a buňky tabulek se zbytečně nafukují

  • v dropdownech narůstá délka položky do nesmyslných délek

  • je to špatně čitelné.

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

  • templatové struktuře by bylo nutné pole pro acronyms doplnit i tam, kde nejsou. Například u Facility, nebo Offices,

  • v GUI interface by se mělo to pole objevit pro ruční zadání

  • u Facility se místo Acronyms dá použít například sloupec CODE, ale je to takový hack.. CODE má sloužit na něco jiného, bývá to nějaký unikátní řetězec, např. registrační číslo členské organizace.

  • U zobrazené zkratky subjektu by stále mělo být k dispozici aby uživatel viděl celý název... Udělat to nějakým ALT nebo TITLE tagem...

-- 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ů.

Díky moc za debatní kolečko.. Co se týče case-sensitive, tak ano jsem si toho vědom, ale nepozorností mi to někdy unikne. A pak to nejde importovat. :) Co se týče nějaké té diskuse na GitHubu, tak určitě dobré brát v úvahu co říkají, říkají to vesměs jako nějakou praktickou zkušenost. Ale někdy z nich vidím evidentní nechuť that kostlivce ze skříně. 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: - se neušetří prostor a buňky tabulek se zbytečně nafukují - v dropdownech narůstá délka položky do nesmyslných délek - je to špatně čitelné. 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 - templatové struktuře by bylo nutné pole pro acronyms doplnit i tam, kde nejsou. Například u Facility, nebo Offices, - v GUI interface by se mělo to pole objevit pro ruční zadání - u Facility se místo Acronyms dá použít například sloupec CODE, ale je to takový hack.. CODE má sloužit na něco jiného, bývá to nějaký unikátní řetězec, např. registrační číslo členské organizace. - U zobrazené zkratky subjektu by stále mělo být k dispozici aby uživatel viděl celý název... Udělat to nějakým ALT nebo TITLE tagem... -- 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ů.
Podhorecky commented 2018-03-14 22:57:02 +01:00 (Migrated from git.spotter.cz)

changed milestone to %2

changed milestone to %2
Sign in to join this conversation.
No Label
app-sahana
upstream
No Milestone Sahana Eden bugreport
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Spotter-Cluster/Spotter-VM#27
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?