dashiwa
commented
5 years ago @orion76 Вероятно так - Энтити с кастомным полем имеющим start и end колонки в числовом формате.
Open dashiwa opened 5 years ago
dashiwa
commented
5 years ago @orion76 Вероятно так - Энтити с кастомным полем имеющим start и end колонки в числовом формате.
orion76
commented
5 years ago @dashiwa да.. числовые (integer) поля для хранения timestamp и так же необходимо поле связи (entityreference) для связи с выполняемой задачей над остальными полями надо еще подумать, возможно в процессе работы будет понятнее, что еще надо
В Битрикс CRM это неплохо устроено: 1.В процессе работы исполнитель просто стартует и останавливает таймер. 2.В БД сохраняются "интервалы" "отрезков" времени работы.
PS.
и так же необходимо поле связи (entityreference) для связи с выполняемой задачей
Хотя нет, поле связи наверное не надо, правильнее добавить поле-связи с этой сущностью в сущность Задача (или любую другую)
dashiwa
commented
5 years ago @orion76 Сделал. Field
1.Хранение данных пока в формате строки (были некоторе сомнения , можно доработать)
Нужно подкорректировать пр, вычистить лишний коммит.
Пока есть "модель" для хранения данных. Интерфейс загрузки данных будет сложнее его нужно будет обсудить
orion76
commented
5 years ago (из скайпа) По поводу записи данных я думаю будет такой алгоритм
- Пользователь нажимает на кнопку (проверяем сессию - может уже нажал)) - делаем сабмит в > первый инпут (старт тайм)
- Создаем сессию - (тайм трекер запущен)
- Нажимаем на кнопку опять. - Проверяем сессию. Если уже она есть. Пишем во второй инпут (end time) .
- Ну и разобратся как вывести форму
Про сессию надо подумать. Теоретически, она нужна только если Кнопка будет располагаться на нескольких или даже на всех открытых страницах сайта.
Ну вообще-то да.. удобнее было-бы, чтобы включить-отключить таймер можно было с любой страницы сайта.
Тут возникает несколько нюансов-) Таймер должен быть связан с задачей, подсчет времени выполнения которой он ведет.
Значит включать таймер, проще и логичнее на странице задачи. Чтобы была возможность включать таймер на любой странице, должен быть интерфейс выбора задачи, для которой включается таймер.
Представляю себе это так:
блок таймера содержит следующие элементы:
Тогда получается структура данных таймера должна быть немного другой. Т.е. для сущности "Интервал таймера" нужна еще сущность-контейнер "Таймер", в которой уже будет многострочное поле entityreference "Интервалы таймера".
И сущность по которой таймер должен вести подсчет (в данном случае Задача) тоже должна быть полем Таймера, а не наоборот Таймер - поле сущности Задача. Так будет проще добиться слабой связанности Таймера с сущностями, по которым он будет вести подсчет времени.
т.е. в общих чертах так: 1.Сущность "Интервал таймера" поля:
2.Сущность "Таймер" поля:
dashiwa
commented
5 years ago 
@orion76 Дополнение
Стрелочки сплошные это связи один ко многим. С черточками 1 к 1 Начиная с пользователя Соответсвенно 1 задача может иметь 1 таймер и много интервалов Таймер это энтити(пока без связей к чему либо) Интервал это филда которая содержит два значения, количество настраивается из коробки от 1 до бесконечности Работает человек в неделю по 2-3-5 часов к примеру..в день Это уже реализовано
Вместо сессии думаю можно использовать куку с идентификатором задачи и ид юзера, чтобы разные юзеры не могли перетирать статус таймера (то есть просто куку типо timer_status - ON или OFF так как она на клиенте будет а если сессия то можно и айдишник пихать и тд)
так вроде поменьше сущностей будет
orion76
commented
5 years ago кстати.. да.. про кастомное поле сущности из нескольких "суб-полей" (StartTime, BeginTime)у меня из головы вылетело-)
Про куки и сессии.. Давно не возился, подзабыл.. А как сессию кто-то может перетереть?
Если айди и статус таймера в куках хранить, то если например будут открыты несколько страниц сайта, может оказаться так что данные кук на них будут разные (айди и статус задачи)
Получается в куках можно хранить только айди сессии-) а это уже сессии-) Айди сессии будет для всех страниц одно. Данные сессии (в БД) так же будут для всех страниц одни. Тогда получается, логичнее использовать сессии.
Кстати, в drupal 8 для этого специальный сервис есть: https://www.anubavam.com/blogs/how-store-session-data-drupal-8
dashiwa
commented
5 years ago Про куки и сессии - виноват , нужно базу подтянуть.
orion76
commented
5 years ago Дальше какие подзадачи на очереди?
Чтобы прямо в ишью было наглядно видно на каком этапе находиться задача, давай в топике TODO- список подзадач выводить, отсортированный по приоритетам:
Например
и т.п.
dashiwa
commented
5 years ago @orion76 Отличная затея.. Я видел примеры этих чекбоксов у других репозиториев По приоритету все верно. Блок следующий
orion76
commented
5 years ago /**
* Defines the 'timestamp' entity field type.
*
* @FieldType(
* id = "timestamp",
* label = @Translation("Timestamp"),
* description = @Translation("An entity field containing a UNIX timestamp value."),
* default_widget = "datetime_timestamp",
* default_formatter = "timestamp",
* constraints = {
* "ComplexData" = {
* "value" = {
* "Range" = {
* "min" = "-2147483648",
* "max" = "2147483648",
* }
* }
* }
* }
* )
*/
class TimestampItem extends FieldItemBase {
/**
* {@inheritdoc}
*/
public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
$properties['value'] = DataDefinition::create('timestamp')
->setLabel(t('Timestamp value'))
->setRequired(TRUE);
return $properties;
}
т.е. блок с кнопкой и таймером. нажал Старт создалась сущность "Диапазон" с временем начала отсчета нажал Стоп - в сущность Диапазон добавилось время конца отсчета и она сохранилась в БД.