Доработка на секции и полета в портала

governmentbg / opendata

Това хранилище е извадено от употреба. Актуално хранилище:

https://github.com/governmentbg/data-gov-bg

MIT License

27 stars 6 forks source link

Доработка на секции и полета в портала #31

Open antitoxic opened 8 years ago

antitoxic commented 8 years ago

дата на валидност на даден набор от данни;
секция с документи – лицензи, график, РМС 103 и др.;
инструкции за качване на данни;
връзки към инструментите за автоматизирано качване на данни;

RadoRado commented 8 years ago

Обмислям да захвана това issue.

Имам нужда от повече яснота по съответните точки - кое какво означава и какво се търси като резултат :panda_face:

Нека започнем с първото - дата на валидност на даден набор от данни;

От къде да се set-ва тази дата? (Предполагам от UI-а, в който се добавя набор от данни)
Какъв ще е state-а на едни данни - валидни, невалидни? Или ще има междинен state.
- Ще има ли коментар към този state - защо например данните изтичат на тази дата?
Спрямо state-а - как го визуализираме - "ТЕЗИ ДАННИ СА В СРОК" / "ТЕЗИ ДАННИ НЕ СА В СРОК"
Ще има ли по-строго enforce-ване за данни с изтекъл срок?

Ще се радвам на яснота, за да мога да започна да атакувам проблема :smile_cat:

antitoxic commented 8 years ago

Да, от формичката за добавяне на данните.
Няма да има "state" засега само дата. State-a ще е динамично извлечен от датата (ако е преди датата на изтичане -> валиден, ако е след -> невалиден). Идеята за коментар е яка. Правим го - тоест сложи и едно поле "Защо изтичат тогава" или "Обосновка за срока на валидност". Wording-a най-накрая може да го оправим
Ако намериш в сайта някъде каре, което се ползва при грешка (нещо тип bootstrap alert-error , alert-success) може да преизползваме това каре и спрямо датата да излиза "актуални" или "outdated".
Засега не. Може като допълнително issue.

RadoRado commented 8 years ago

Супер, благодаря за разяснението. Поемам по тази задача :panda_face:

RadoRado commented 8 years ago

От това, което проучих днес има (горе-долу) следните 2 варианта:

Вариант 1 - Rambo style - Пишем директно в CKAN

Може да се plug-нем в HTML-а тук - https://github.com/obshtestvo/ckan/blob/master/ckan/templates/package/snippets/package_basic_fields.html
Може да се plug-нем в controller-а тук - https://github.com/obshtestvo/ckan/blob/master/ckan/controllers/package.py#L517 (и на още няколко места, където повтарят 1 и същи код)
Може да се plug-нем във models тук - https://github.com/obshtestvo/ckan/blob/master/ckan/model/package.py#L34

Така ще постигнем желаният ефект.

Днес успях да се plug-на успешно в HTML-а и горе-долу проследих логиката

Това, което не ми харесва е, че има повторение на код и логиката е доста абстрактна / сложна.

Вариант 2 - CKAN Extension

Тъй като CKAN се промотира като WordPress за данни, то има начин да се пишат extensions

Това, което видях е, че има начин да направим точно това, което ни трябва на нас - http://docs.ckan.org/en/latest/extensions/adding-custom-fields.html

Единственият минус, който виждам е следният:

Мястото, където се показват тези custom fields е фиксирано и се намира м/у URL и Description-a - https://github.com/obshtestvo/ckan/blob/master/ckan/templates/package/snippets/package_basic_fields.html#L16

Не съм проучвал други места за plug-ване чрез extension„ но от бързият поглед в/у документацията - има.

Мнения? :panda_face:

На мен лично extension метода ми харесва много повече.

п.с. Като прегледах https://github.com/ckan/ckan/wiki/List-of-extensions нямаше това, което ни трябва на нас.

RadoRado commented 8 years ago

Днес имах доста продуктивен ден :smile_cat:

Успях да подкарам CKAN extension, който да добавя custom metafields към формата за създаване / редактиране на dataset + view–то, което показва конкретен dataset.

Направих и простата проверка за изтекла дата на даден dataset.

Въпреки, че на няколко пъти трябваше да бъркам по CKAN-а, в крайна сметка намерих начин как всичко да стане само през extension–а.

Кодът се намира тук - https://github.com/RadoRado/ckanext-extrafields (нямам права да създавам repositories в obshtestvo)

За да тествате. може да разцъкате ето тук - http://46.101.159.241/

В картинки, това изглежда така:

Двете полета във формата

Освен, че добавих двете полета във формата, премахнах 3те "extra fields". Ако искаме extra fields, най-добре е да ги добавяме през extension–а.

Допълнителна информация и "Прясност" на данните

Като се създаде даден набор от данни, в таблицата с "допълнителна" информация отиват 2те нови полета + имаме индикация спрямо прясността на данните:

Ето и изтекли данни:

Мотики

Днес настъпих бая мотики, но най-основната беше затрудненото debug-ване на грешки при валидация на поле, добавено от extension - https://github.com/ckan/ckan/issues/2816

Проблемът го реших, като добавих един ред в CKAN–а, да log–вам грешката, за да видя каква точно е тя (в error log-а на Apache, ама това е друга тема):

log.info(e.error_dict)

Като цяло, това е добра стратегия, за да debug-неш CKAN-а, ако не гърми достатъчно ясно.

Въпроси и какво още има за правене

Тук към @antitoxic

Тези полета трябва ли да бъдат задължителни? Има малко логика, която ще се промени на базата на това решение
Трябва да преведа низовете на български и да форматирам показаните дати
Трябва да добавя валидация за полетата от страна на CKAN - особено за датите
Трябва да тествам още, понеже ударих 1 бъг и към момента не съм го решил много добре.
Трябва да напиша и тестове за extension-а

mitio commented 8 years ago

@RadoRado изглежда доста добре! Това, че си успял да го направиш само в extension, е голяма победа.

Имам дребна бележка относно избора на име на полетата – струва ми се, че "due date" не е най-подходящото име:

due date (noun) – the date on which something falls due, especially the payment of a bill or the expected birth of a baby.

Като мисля за алтернативи, ми идват следните неща наум:

expires_on ("Date of expiry"/"Dataset expiration date")
valid_until ("Dataset valid until")
dataset_date/compiled_on/created_on ("Dataset creation/compilation date") – дата на създаване на набора от данни.

Първите две са сходни и задават докога са актуални данните. Третото е по-различно и указва кога са събрани данните.

Тези различни имена ме наведоха на мисълта какво е редно да се записва в това поле – коя дата би имала най-много смисъл. От там се замислих от гледна точка на потребител на данните и от гледна точка на качващ данните, че вероятно най-полезна би била датата, в която са събрани данните. Нещо като "актуално към". Например, ако данните се обобщават веднъж на месец, тази дата би трябвало да бъде датата, в която е направено обобщението. Не кога са качени на портала ("Създаден"), или кога са редактирани метаданните ("Last updated"), за които мисля, че се попълват автоматично – а кога са събрани/компилирани/обобщени.

Веднъж събран, всеки набор от данни вече е out of date, понеже не е API в реално време. Затова, смятам, че най-полезна би била дата на създаване/събиране/компилиране на набора от данни и, като допълнително поле, може би в свободен текст, с каква честота се обобщават тези данни.

Смятам, че това трябва да се обсъди с Нуша, която има по-добра представа какви набори от данни има и какви нужди имат администрациите, качващи данните.

RadoRado commented 8 years ago

@mitio благодаря за предложенията!

Как да процедираме? Ако ще говорите с някой от stakeholder-ите, може да изчистим като цяло какви допълнителни полета ни трябват при създаване на dataset или качване на ресурс.

Като го имаме, промяната ще стане лесно / бързо.

И докато това се изчисти, мога да продължа по другите точки.

По втората точка - секция с документи – лицензи, график, РМС 103 и др.; - ще ми трябва повече контекст, защото не съм сигурен, че го разбирам - @antitoxic :panda_face:

antitoxic commented 8 years ago

@RadoRado , супер работа :balloon:

@mitio:

Веднъж събран, всеки набор от данни вече е out of date...

Това не е напълно вярно. Качените набори може да са валидни до дата X. Пример: Срокове за .... или Избрани градове за блабла в периода 2015-2020.

@RadoRado:

Тези полета трябва ли да бъдат задължителни? Има малко логика, която ще се промени на базата на това решение

По коментарите на @mitio, нека добави ми още 1 поле - compiled_at. Може ли да направим така, че едно от двете трябва да е попълнено? Ясно, че в базата няма как да се укаже това, но може би някаква валидация? Било то js? Реално за базата и двете ще са optional fields.

Също, именуването на @mitio е супер. Нека полето за дата е expires_on.

Трябва да преведа низовете на български и да форматирам показаните дати

expires_on - До коя дата са актуални данните?

compiled_at - На коя дата са събрани данните?

Този набор от данни е актуален! Актуалността на информацията в него изтича на date.

Този набор от данни не актуален! Информацията в него не е актуално от date.

Трябва да добавя валидация за полетата от страна на CKAN - особено за датите

Виж по-горе.

Трябва да тествам още, понеже ударих 1 бъг и към момента не съм го решил много добре.

Трябва да напиша и тестове за extension-а

Ok. Don't overdo it. В смисъл, супер, но ме ping-ни ако ще отнеме доста време.

RadoRado commented 8 years ago

Ето отчет за какво постигнах до сега в този сравнително продуктивен четвъртък:

Добавих каквото трябваше като полета и направих съответните преименувания. :panda_face:

За да може да тествате, ще пиша в Gitter чата за credentials, да не е твърде public :ear:

Ето и нещата подред:

Добавена валидация

По коментара на @antitoxic направих валидация, на ниво Python / CKAN, поне едно от двете полета да са present - compiled_at или expires_on

Кодът на валидацията се намира тук - https://github.com/RadoRado/ckanext-extrafields/blob/master/ckanext/extrafields/plugin.py#L8

Валидацията се прави след като е минала валидацията на всичките полета. Закачил съм я на някакъв специален __after hook.

Български формат на датите

Където се показват дати (с изключения на HTML date input-a), съм ги направил във формат %d/%m/%Y, за да се чете по-лесно.

Гледам CKAN–а прави доста по описанителни - слага януари и т.н., та ще погледна как го правят те, за да сме консистентни.

Мотики

10506_gallery_main

За съжаление, този guide - http://docs.ckan.org/en/latest/extensions/translating-extensions.html е валиден за CKAN версии > 2.5 и при мен гръмна.

Кодът е готов, имам и преведени string–ове, но те все още не се показват. Когато се мигрира към 2.5.1, махат се 3 коментара и би трябвало да работи, но докато не тесваме няма как да знаем :smile_cat:

Преводите са тук - https://github.com/RadoRado/ckanext-extrafields/blob/master/ckanext/extrafields/i18n/bg/LC_MESSAGES/ckanext-extrafields.po

Това, с което съм се захванал сега е #1 и мигрирането към 2.5.1 - да видя как ще се получи със скрипта.

Допълнителни въпроси

Искаме ли да има ограничение compiled_at <= expires_on ? В момента няма такава валидация, но няма да е проблем да се добави.
В момента има едно поле expiration_info, което е optional за коментар към датата на изтичане. Има ли нужда от compilation_info?

antitoxic commented 8 years ago

Искаме ли да има ограничение compiled_at <= expires_on ? В момента няма такава валидация, но няма да е проблем да се добави.

Не, понеже данните може да са събрани за преден период и да са реално неактуални при качване.

В момента има едно поле expiration_info, което е optional за коментар към датата на изтичане. Има ли нужда от compilation_info?

Няма нужда.

2.5.1 ftw.

RadoRado commented 8 years ago

Така, днес успях да подкарам 2.5.1 с няколко мотики по пътя (#42) и превода работи :panda_face:

Може да видите резултата тук - http://178.62.238.76/dataset/courses-hackbulgaria

Credentials в gitter.

Кодът е качен тук - https://github.com/RadoRado/ckanext-extrafields/

Работят следните сценарии:

Има добавени 3 нови полета - compiled_at, expires_on и expiration_info.
Полетата са незадължителни със следната валидация - поне едно от двете - compiled_at или expires_on трябва да бъде въведено.
Спрямо въведените дати се показва едно червено или едно зелено каре, което казва дали набора е пресен или не.
Ако има дадено допълнително expiration_info и то се показва.
И 3те полета се показват в Additional Info таблицата
Има преводи, като единствено after-а не е преведен, което идва от CKAN валидацията. Не съм го борил, тъй като не ми се стори особено значително.

Странични ефекти

Като страничен ефект от сблъсъка с CKAN extensions се роди това - https://github.com/governmentbg/opendata/blob/master/guides/ckan_extensions.md

Следващи стъпки

Чакам feedback по кода / преводите / семантиката.

Ако всичко е ОК, може да го тестваме на staging, за да се изловят бъгове.

След това мога да минавам към секция с документи – лицензи, график, РМС 103 и др.; :smile_cat:

RadoRado commented 8 years ago

Благодарение на @mihail-ivanov изчистих един бъг от extension-a - https://github.com/RadoRado/ckanext-extrafields :smile_cat:

За да се инсталира, се правят две неща:

$ pip install -e "git+https://github.com/RadoRado/ckanext-extrafields#egg=ckanext-extrafields"
Да се добави extrafields в config-а на CKAN (например production.ini). За момента ще дойде след bulgarian_theme

Чакам следващо включване.