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

antitoxic · 2015-12-28T19:51:56Z

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

RadoRado · 2016-01-20T12:59:06Z

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

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

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

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

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

antitoxic · 2016-01-20T13:09:13Z

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

RadoRado · 2016-01-20T13:56:22Z

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

RadoRado · 2016-01-20T15:59:32Z

От това, което проучих днес има (горе-долу) следните 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„ но от бързият поглед в/у документацията - има.

Мнения? 🐼

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

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

RadoRado · 2016-01-24T18:04:44Z

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

Успях да подкарам 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 - ckan/ckan#2816

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

log.info(e.error_dict)

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

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

Тук към @antitoxic

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

mitio · 2016-01-25T09:00:42Z

@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 · 2016-01-25T16:56:36Z

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

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

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

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

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

antitoxic · 2016-01-26T06:56:02Z

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

@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 · 2016-01-28T16:50:13Z

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

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

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

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

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

По коментара на @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–а прави доста по описанителни - слага януари и т.н., та ще погледна как го правят те, за да сме консистентни.

Мотики

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

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

Преводите са тук - 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 · 2016-01-28T18:32:47Z

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

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

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

Няма нужда.

2.5.1 ftw.

RadoRado · 2016-02-01T15:23:40Z

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

Може да видите резултата тук - 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 и др.; 😸

RadoRado · 2016-02-25T17:14:18Z

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

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

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

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

antitoxic added the функционалност label Dec 28, 2015

antitoxic added this to the Етап 1 milestone Dec 28, 2015

antitoxic mentioned this issue Dec 28, 2015

Начало на работа от екип "Общество" #34

Open

RadoRado self-assigned this Jan 20, 2016

antitoxic mentioned this issue Jan 26, 2016

Инструменти за автоматично качване #35

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

antitoxic commented Dec 28, 2015

RadoRado commented Jan 20, 2016

antitoxic commented Jan 20, 2016

RadoRado commented Jan 20, 2016

RadoRado commented Jan 20, 2016

RadoRado commented Jan 24, 2016

mitio commented Jan 25, 2016

RadoRado commented Jan 25, 2016

antitoxic commented Jan 26, 2016

RadoRado commented Jan 28, 2016

antitoxic commented Jan 28, 2016

RadoRado commented Feb 1, 2016

RadoRado commented Feb 25, 2016

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

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

Comments

antitoxic commented Dec 28, 2015

RadoRado commented Jan 20, 2016

antitoxic commented Jan 20, 2016

RadoRado commented Jan 20, 2016

RadoRado commented Jan 20, 2016

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

Вариант 2 - CKAN Extension

RadoRado commented Jan 24, 2016

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

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

Мотики

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

mitio commented Jan 25, 2016

RadoRado commented Jan 25, 2016

antitoxic commented Jan 26, 2016

RadoRado commented Jan 28, 2016

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

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

Мотики

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

antitoxic commented Jan 28, 2016

RadoRado commented Feb 1, 2016

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

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

RadoRado commented Feb 25, 2016