Entity and interfaces for time tracker functionality

[dashiwa]

т.е. блок с кнопкой и таймером.
нажал Старт создалась сущность "Диапазон" с временем начала отсчета
нажал Стоп - в сущность Диапазон добавилось время конца отсчета и она сохранилась в БД.

[dashiwa]

@orion76 Вероятно так -
Энтити с кастомным полем имеющим start и end колонки в числовом формате.

[orion76]

@dashiwa
да.. числовые (integer) поля для хранения timestamp
и так же необходимо поле связи (entityreference) для связи с выполняемой задачей
над остальными полями надо еще подумать, возможно в процессе работы будет понятнее, что еще надо

В Битрикс CRM это неплохо устроено:
1.В процессе работы исполнитель просто стартует и останавливает таймер.
2.В БД сохраняются "интервалы" "отрезков" времени работы.
3. При необходимости, исполнитель на специальной странице может:

• подкорректировать интервал (например если забыл отключить таймер)
• удалить интервалы
• добавить новый (если например забыл включить таймер-)

PS.

и так же необходимо поле связи (entityreference) для связи с выполняемой задачей

Хотя нет, поле связи наверное не надо, правильнее добавить поле-связи с этой сущностью в сущность Задача (или любую другую)

[dashiwa]

@orion76 Сделал. Field

1.Хранение данных пока в формате строки (были некоторе сомнения , можно доработать)
2. Поле содержит виджет с двумя инпутами - стартовое время и конечное время
3. Проверка - Стартовое время не может быть больше чем конечное
4. Сделан форматтер в виде простого списка
Пример
10
100
5. Все работает корректно и возможно присоединять данное поле к любой сущности, корректно работает множественные значения поля(может пригодится) . Стоит простой фильтр на xss

Нужно подкорректировать пр, вычистить лишний коммит.

Пока есть "модель" для хранения данных.
Интерфейс загрузки данных будет сложнее его нужно будет обсудить

[orion76]

(из скайпа) По поводу записи данных я думаю будет такой алгоритм

1. Пользователь нажимает на кнопку (проверяем сессию - может уже нажал)) - делаем сабмит в > первый инпут (старт тайм)
2. Создаем сессию - (тайм трекер запущен)
3. Нажимаем на кнопку опять. - Проверяем сессию. Если уже она есть. Пишем во второй инпут (end time) .
4. Ну и разобратся как вывести форму

Про сессию надо подумать.
Теоретически, она нужна только если Кнопка будет располагаться на нескольких или даже на всех открытых страницах сайта.

Ну вообще-то да.. удобнее было-бы, чтобы включить-отключить таймер можно было с любой страницы сайта.

Тут возникает несколько нюансов-)
Таймер должен быть связан с задачей, подсчет времени выполнения которой он ведет.

Значит включать таймер, проще и логичнее на странице задачи.
Чтобы была возможность включать таймер на любой странице, должен быть интерфейс выбора задачи, для которой включается таймер.

Представляю себе это так:

блок таймера содержит следующие элементы:

1. Кнопка таймера с индикацией состояния.
   т.е. на кнопке Включенного таймера должен быть текст "Стоп" (или что-то подобное)
   на кнопке ВЫключенного таймера должен быть текст "Старт"
   возможно состояния таймера должны "визуализироваться" еще и разными цветами кнопки
2. Текущее значение таймера (часы-минуты) для текущей задачи.
3. Наименование текущей задачи (возможно с ссылкой на саму задачу)
4. В перспективе, должен быть еще "список" задач(или уже когда-то включенных таймеров), для того чтобы можно было выбрать таймер для другой задачи (отличной от текущей).

Тогда получается структура данных таймера должна быть немного другой.
Т.е. для сущности "Интервал таймера" нужна еще сущность-контейнер "Таймер", в которой уже будет многострочное поле entityreference "Интервалы таймера".

И сущность по которой таймер должен вести подсчет (в данном случае Задача) тоже должна быть полем Таймера, а не наоборот Таймер - поле сущности Задача.
Так будет проще добиться слабой связанности Таймера с сущностями, по которым он будет вести подсчет времени.

т.е. в общих чертах так:
1.Сущность "Интервал таймера"
поля:

• Начало отсчета
• Конец отсчета

2.Сущность "Таймер"
поля:

• Интервалы (многострочное поле entityreference на сущность "Интервал таймера")
• Задача (поле entityreference на сущность, по которой ведется учет времени)

[dashiwa]

@orion76 Дополнение

Стрелочки сплошные это связи один ко многим. С черточками 1 к 1
Начиная с пользователя
Соответсвенно 1 задача может иметь 1 таймер и много интервалов
Таймер это энтити(пока без связей к чему либо)
Интервал это филда которая содержит два значения, количество настраивается из коробки от 1 до бесконечности
Работает человек в неделю по 2-3-5 часов к примеру..в день
Это уже реализовано

Вместо сессии думаю можно использовать куку с идентификатором задачи и ид юзера, чтобы разные юзеры не могли перетирать статус таймера (то есть просто куку типо timer_status - ON или OFF так как она на клиенте будет а если сессия то можно и айдишник пихать и тд)

так вроде поменьше сущностей будет

[orion76]

кстати.. да.. про кастомное поле сущности из нескольких "суб-полей" (StartTime, BeginTime)у меня из головы вылетело-)

Про куки и сессии..
Давно не возился, подзабыл..
А как сессию кто-то может перетереть?

Если айди и статус таймера в куках хранить, то если например будут открыты несколько страниц сайта, может оказаться так что данные кук на них будут разные (айди и статус задачи)

Получается в куках можно хранить только айди сессии-) а это уже сессии-)
Айди сессии будет для всех страниц одно.
Данные сессии (в БД) так же будут для всех страниц одни.
Тогда получается, логичнее использовать сессии.

Кстати, в drupal 8 для этого специальный сервис есть:
https://www.anubavam.com/blogs/how-store-session-data-drupal-8

[dashiwa]

Про куки и сессии - виноват , нужно базу подтянуть.

[orion76]

Дальше какие подзадачи на очереди?

Чтобы прямо в ишью было наглядно видно на каком этапе находиться задача, давай в топике TODO- список подзадач выводить, отсортированный по приоритетам:

Например

• - Контент-сущность таймтреккера
• - Поле диапазона времени
• - Блок включения-выключения таймтреккера

• • - Аякс роут обработки запросов включения-отключения таймера
• • - плагин Context текущего состояния таймера
• • - сервис обработки логики таймтреккера

и т.п.

[dashiwa]

@orion76 Отличная затея.. Я видел примеры этих чекбоксов у других репозиториев
По приоритету все верно. Блок следующий

[orion76]

/**
 * 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;
  }