Добавить пользователям конфигурационный параметр "каталог протоколов"

[alx]

В [56/base] пользователю дана возможность открывать протокол тестирования кликом ссылки. По этому поводу у меня есть сразу несколько соображений.

1. В сообщении коммита написано, что для правильной работы этой функции требуется, чтобы пользователь установил путь к каталогу, в котором у него содержатся протоколы, в 93 строке файла testing.php. Но, это вряд ли возможно, так как, во-первых, как пользователь сможет модифицировать хранящийся на сервере файл? У него нет (и не должно быть) прав модификации этого файла! А во-вторых (и главных), файл на сервере один, а пользователей - много. Следовательно, максимум один из пользователей сможет пользоваться этой функцией.

Предлагаю добавить пользователям настройку пути к каталогу протоколов, которую хранить в базе данных для каждого пользователя, и сделать пользователям интерфейс для управления этой настройкой.

2. Насколько я вижу, файл протокола ищется по наличию номера протокола в имени файла. Здесь есть сразу две проблемы:
   • номер протокола может отсутствовать в имени файла (так как нет стандарта на именование файлов протоколов), и тогда файл не будет найден (false negative);
   • номер протокола может быть частью номера другого протокола (например протокол номер D12345 и протокол номер D12345-2), что приведет к отображению "лишнего" или просто не того файла (false positive).

Предлагаю вместо реализованного в [56/base] механизма просто хранить протоколы в базе данных. Для этого: в форме тестирования вместо указания номера протокола пользователь сразу загружает на сервер файл протокола. В дальнейшем при выводе информации о тестировании, если в базе есть протокол, выводить ссылку для его скачивания. Плюсы такого варианта:

• это снижает вероятность ошибки ввода номера протокола, в результате которой протокол потом невозможно найти;
• это позволяет автоматизировать присваивание номеров протоколам, исключая возможность существования нескольких протоколов с одинаковыми номерами;
• это затруднит нерадивым (я уверен, что у нас таких нет, но все-таки) пользователям выполнять проверки без составления протокола;
• отпадает необходимость реализации предложения п. 1 выше.

[san]

Предлагаю добавить пользователям настройку пути к каталогу протоколов, которую хранить в базе данных для каждого пользователя, и сделать пользователям интерфейс для управления этой настройкой.

В этом нет необходимости, т.к. директория хранения протоколов общая для всех пользователей.

номер протокола может отсутствовать в имени файла
так как нет стандарта

Есть договорённость, по которой серийный номер изделия обязан быть в имени файла протокола. Сейчас протоколами пользуются полагаясь на это правило.

номер протокола может быть частью номера другого протокола (например протокол номер D12345 и протокол номер D12345-2

В интерфейсе выводятся имена файлов всех протоков изделия с заданным серийным номером, а пользователь уже выбирает какой конкретно ему нужен.

Предлагаю ... просто хранить протоколы в базе данных

А что значит в базе?
Дело в том, что протоколы уже хранятся(и используются) в определённой директории на R2, на этом шаге предполагается что интерфейс базы сможет их отобразить пользователю.
А на следующем шаге планируется, что пользователь сможет загружать протокол в эту же директорию через интерфейс базы.

[alx]

Replying to san:

В этом нет необходимости, т.к. директория хранения протоколов общая для всех пользователей.

То есть как? Я вот уверен, что у меня нет каталога "C:/Users/Neolined/Documents". И (почти) уверен, что у тебя нет каталога "/home/alx/Документы", каковой есть у меня... :)

В интерфейсе выводятся имена файлов всех протоков изделия с заданным серийным номером, а пользователь уже выбирает какой конкретно ему нужен.

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

Предлагаю ... просто хранить протоколы в базе данных

А что значит в базе?

Не понял вопрос... Это и значит - записывать и хранить протоколы в базе данных. Я по-моему подробно описал свое предложение - когда пользователь заносит запись о проведенном испытании, он одновременно c другими данными (результат, комментарий и не помню что там еще) передает протокол.

Дело в том, что протоколы уже хранятся(и используются) в определённой директории на R2, на этом шаге предполагается что интерфейс базы сможет их отобразить пользователю.

А, понятно. Я об этом не знал... А как они туда попадают?

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

Ну можно и так...

[san]

А как они туда попадают?

Их туда копируют по SMB сотрудники производства, после проверки изделия.

Планировалось не трогать сложившиеся устои, а лишь добавить более удобный вариант поиска и добавления протокола.

[alx]

Посмотрел протестированные изделия. За сегодня ни одного протокола из четырех не нашел. Может еще не успели загрузить, хотя с окончания последней проверки прошло больше двух часов, но хорошо, не будем сегодняшние учитывать. :)

Из следующих 10 проверенных изделий протоколы имеются только на 7. Придет, допустим, аудитор и скажет: "А покажите-ка мне протокол проверки изделия E01065!" - а у нас его нетути... :)

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

[alx]

Навеяно комментариями к #874, но по теме больше подходит к этому тикету, поэтому пишу сюда. Общий вывод попробую сделать в конце.

Я сделал простенький скрипт, который читает из истории БД записи о тестировании изделий и проверяет наличие в каталоге /media/pto/Протоколы испытаний хотя бы одного файла с номером протокола в имени. Резльтаты превзошли мои худшие опасения. Статистику разбивал по месяцам чтобы исключить оправдания типа "базой только-только начали пользоваться". :)

Объясню, что здесь выводится.

Protocol is NULL

в поле protocol записано NULL (как такое вообще возможно?).

Protocol is empty

в поле protocol - пустая строка.

Protocol not found

в поле протокола непустая строка, но ни одного файла с такой сторокой в имени не найдено.

Protocol is OK

в поле протокола непустая строка и найден как минимум один файл с такой строкой в имени (что еще не означает, что так содержится нужный протокол - см. комментарии выше).

========= 2021.5 =======
Protocol is OK:       20 of 51 (39 %)
Protocol is NULL:      0 of 51 (0 %)
Protocol is empty:    23 of 51 (45 %)
Protocol not found:    8 of 51 (15 %)
========= 2021.6 =======
Protocol is OK:        7 of 13 (53 %)
Protocol is NULL:      0 of 13 (0 %)
Protocol is empty:     6 of 13 (46 %)
Protocol not found:    0 of 13 (0 %)
========= 2021.7 =======
Protocol is OK:       34 of 258 (13 %)
Protocol is NULL:      0 of 258 (0 %)
Protocol is empty:   204 of 258 (79 %)
Protocol not found:   20 of 258 (7 %)
========= 2021.8 =======
Protocol is OK:       53 of 206 (25 %)
Protocol is NULL:      0 of 206 (0 %)
Protocol is empty:   153 of 206 (74 %)
Protocol not found:    0 of 206 (0 %)
========= 2021.9 =======
Protocol is OK:       56 of 157 (35 %)
Protocol is NULL:      0 of 157 (0 %)
Protocol is empty:    94 of 157 (59 %)
Protocol not found:    7 of 157 (4 %)
========= 2021.10 =======
Protocol is OK:       86 of 200 (43 %)
Protocol is NULL:      0 of 200 (0 %)
Protocol is empty:    92 of 200 (46 %)
Protocol not found:   22 of 200 (11 %)
========= 2021.11 =======
Protocol is OK:      204 of 409 (49 %)
Protocol is NULL:      0 of 409 (0 %)
Protocol is empty:   200 of 409 (48 %)
Protocol not found:    5 of 409 (1 %)
========= 2021.12 =======
Protocol is OK:       79 of 226 (34 %)
Protocol is NULL:      0 of 226 (0 %)
Protocol is empty:   101 of 226 (44 %)
Protocol not found:   46 of 226 (20 %)
========= 2022.1 =======
Protocol is OK:      102 of 369 (27 %)
Protocol is NULL:      0 of 369 (0 %)
Protocol is empty:   197 of 369 (53 %)
Protocol not found:   70 of 369 (18 %)
========= 2022.2 =======
Protocol is OK:      242 of 703 (34 %)
Protocol is NULL:      0 of 703 (0 %)
Protocol is empty:   201 of 703 (28 %)
Protocol not found:  260 of 703 (36 %)
========= 2022.3 =======
Protocol is OK:      153 of 357 (42 %)
Protocol is NULL:      0 of 357 (0 %)
Protocol is empty:     1 of 357 (0 %)
Protocol not found:  203 of 357 (56 %)
========= 2022.4 =======
Protocol is OK:      123 of 234 (52 %)
Protocol is NULL:      0 of 234 (0 %)
Protocol is empty:    16 of 234 (6 %)
Protocol not found:   95 of 234 (40 %)
========= 2022.5 =======
Protocol is OK:      109 of 217 (50 %)
Protocol is NULL:      0 of 217 (0 %)
Protocol is empty:    49 of 217 (22 %)
Protocol not found:   59 of 217 (27 %)
========= 2022.6 =======
Protocol is OK:      104 of 208 (50 %)
Protocol is NULL:      0 of 208 (0 %)
Protocol is empty:    19 of 208 (9 %)
Protocol not found:   85 of 208 (40 %)
========= 2022.7 =======
Protocol is OK:       55 of 125 (44 %)
Protocol is NULL:      0 of 125 (0 %)
Protocol is empty:     8 of 125 (6 %)
Protocol not found:   62 of 125 (49 %)
========= 2022.8 =======
Protocol is OK:      345 of 714 (48 %)
Protocol is NULL:      0 of 714 (0 %)
Protocol is empty:    36 of 714 (5 %)
Protocol not found:  333 of 714 (46 %)
========= 2022.9 =======
Protocol is OK:      115 of 233 (49 %)
Protocol is NULL:      0 of 233 (0 %)
Protocol is empty:    12 of 233 (5 %)
Protocol not found:  106 of 233 (45 %)
========= 2022.10 =======
Protocol is OK:      427 of 696 (61 %)
Protocol is NULL:      0 of 696 (0 %)
Protocol is empty:     4 of 696 (0 %)
Protocol not found:  265 of 696 (38 %)
========= 2022.11 =======
Protocol is OK:      302 of 526 (57 %)
Protocol is NULL:      0 of 526 (0 %)
Protocol is empty:    22 of 526 (4 %)
Protocol not found:  202 of 526 (38 %)
========= 2022.12 =======
Protocol is OK:      198 of 481 (41 %)
Protocol is NULL:     63 of 481 (13 %)
Protocol is empty:   155 of 481 (32 %)
Protocol not found:   65 of 481 (13 %)

Обратите внимание - самый высоки процент нахождения файлов протоколов - 57% в прошлом месяце (проценты в сумме не всегда дают 100 - это из-за округления).

Вообще-то OK должно быть 100% в каждом месяце**

Как говорил агент Смит, не поручайте человеку то, что может сделать машина. По моему мнению причина проблемы - недостаточная автоматизация и контроль за вводом данных. Часть номеров протоколов, наверное, забыли ввести (и ни фронтенд, ни бэкенд этого не проконтролировали!), часть ввели, но с ошибкой, а часть файлов протоколов забыли потом загрузить на сервер (так как для пользователя это две отдельные операции, а не одна)...

Вывод: при реализации процессов надо:

• автоматизировать все, что только возможно;
• минимизировать число пользовательских операций;
• максимально жестко валидировать все входные данные - тогда система помогает пользователю избежать случайных ошибок, сохраняя данные в относительном порядке. Если же в одном месте дать свободу "на всякий случай", потом еще в паре мест - в результате получается вместо валидных данных NULL и пустые строки...

Пока что создал тикеты #1022 и #1023.

[alx]

Обнаружил, что значения NULL появились только 26 декабря, и ВСЕ записи начиная с 27110 имеют значение NULL.

Видимо, что-то сломали при обновлении.

А здесь я хотел на этом примере добавить, что неплохо было бы при проектировании БД сразу предусмотреть валидацию записываемых данных средствами СУБД (дополнительно к фронтенду). Если бы запись типа testing в таблицу history автоматически проверялась СУБД на наличие значения в поле protocol, ошибка обнаружилась бы сразу 26 декабря, а не спустя 3 дня, когда в БД уже 63 дефектные записи...

[san]

Да тут целое исследование)
Да, с полем протокол была беда, то что туда вводили пользователи вносило ещё больший беспорядок, от этого поля сейчас отказались (ticket:1022#comment:3)

Вывод: при реализации процессов надо:

• автоматизировать все, что только возможно;
• минимизировать число пользовательских операций;
• максимально жестко валидировать все входные данные - тогда система помогает пользователю избежать случайных ошибок, сохраняя данные в относительном порядке. Если же в одном месте дать свободу "на всякий случай", потом еще в паре мест - в результате получается вместо валидных данных NULL и пустые строки...

Тут не поспоришь.

Думаю что когда пользователь будет обязан при тестировании сразу загружать файл протокола в базу (#1024), наступит относительный порядок.
Было бы совсем хорошо если бы и сам протокол пользователь заполнял через интерфейс базы, но для этого нужно "переделать" все протоколы но это довольно затратно и организационно сложно, может быть

[alx]

Replying to san:

Было бы совсем хорошо если бы и сам протокол пользователь заполнял через интерфейс базы, но для этого нужно "переделать" все протоколы но это довольно затратно и организационно сложно, может быть

Меня эта мысль тоже посещала, но я не посчитал это существенным улучшением. Я посчитал преимуществом разве что возможность автоматической генерации номеров протоколов... Кстати, в БД номеров протоколов теперь нет. Следует ли убрать номера и из самих протоколов? А то странно получается - проверяющий должен "вручную" присваивать протоколам номера, которые никому не нужны...

А что ты имел в виду, говоря "затратно"? На что затраты?

[san]

А что ты имел в виду, говоря "затратно"? На что затраты?

Времени сотрудников. Нужно переделать протоколы всех изделий из формата "документ ворд" в машино-понятный формат. И при сдаче нового протокола(изменении старого) нужно в этом новом формате сдавать протокол.

не посчитал это существенным улучшением

Тут есть плюсы:

• для заполнения протокола используется тот же интерфейс что и для отметки о проверке(не нужно открывать протокол другой программой)
• корректность ввода и границы параметров проверяются автоматически и автоматически выносится вердикт о соответствии изделия требованиям
• протокол сохраненный в таком формате будет пригоден для машинной обработки

Следует ли убрать номера и из самих протоколов? А то странно получается - проверяющий должен "вручную" присваивать протоколам номера, которые никому не нужны...

В протоколах нет номеров протоколов, в них указаны серийные номера проверяемых изделий, вот пример из протокола:

Протокол от 26.01.2023 проведения испытаний платы SM-02 № F00131 ...

В примере F00131 - серийный номер платы SM-02

[alx]

Replying to san:

А что ты имел в виду, говоря "затратно"? На что затраты?

Времени сотрудников. Нужно переделать протоколы всех изделий из формата "документ ворд" в машино-понятный формат.

Понятно.

И при сдаче нового протокола(изменении старого) нужно в этом новом формате сдавать протокол.

Насколько я понимаю, его вообще не требуется сдавать. Согласно стандарту, сдавать в архив при изменении требуется только документы. Сейчас протокол является приложением к документу "Программа и методика испытаний", поэтому изменения в протоколе изменяют и ПМ, в результате ее надо сдавать в архив. Но есть протокол отделить от ПМ, он сам по себе уже не будет документом (так как это только форма протокола, "заготовка", "полуфабрикат"). Следовательно, и сдавать в архив такую "заготовку" не требуется...

не посчитал это существенным улучшением

Тут есть плюсы:

Да, я понимаю, что они есть. Просто я в свое не посчитал из достаточно существенными чтобы предлагать это сделать или даже обсудить... :)

• корректность ввода и границы параметров проверяются автоматически и автоматически выносится вердикт о соответствии изделия требованиям

Вот это мне в голову не приходило. :) Да, это избавило бы от необходимости сравнивать измеренное значение с допустимым диапазоном. К сожалению, такие измерения обычно составляют исчезающе малый процент проверок...

Следует ли убрать номера и из самих протоколов? А то странно получается - проверяющий должен "вручную" присваивать протоколам номера, которые никому не нужны...

В протоколах нет номеров протоколов,

Как нет?

в них указаны серийные номера проверяемых изделий, вот пример из протокола:

Протокол от 26.01.2023 проведения испытаний платы SM-02 № F00131 ...

В примере F00131 - серийный номер платы SM-02

Я всегда думал (и соответственно писал), что это номер протокола, а не платы! Если это номер платы, то непонятно, зачем номер платы указывается в протоколе дважды - один раз в заголовке, и второй раз в заключении...

[san]

один раз в заголовке, и второй раз в заключении.

Это просто ошибка в первых шаблонах протоколов, которая распространилась на все, там было много лишнего, всякие ОТК и начальники производства указывались, ну и номер платы дублировался.
В каких-то свежих протоколах от лишнего избавились, в каких-то осталось.
Но номера протокола не существует, по крайней мере я его никогда не встречал и не слышал о нём.
В поле protocol в базе вносилось что попало, потому-что было не оговорено и не понятно было что там указывать)

[alx]

Replying to san:

Это просто ошибка в первых шаблонах протоколов,

Понял. Тогда я при удобном случае удалю один из них.

[san]

Milestone deleted