Запрет добавления записи по условию.

[triadax]

Здравствуйте. Имеется задача: Формируется заявка на определённую дату. В заявку из списка выбирается уникальный номер. Как запретить добавление записи, если дата и номер совпадают с уже имеющейся заявкой?

[support]

Нет такой возможности.

[triadax]

Нет такой возможности.

Очень жаль. Хорошо если бы имелась возможность задавать условия "И", "ИЛИ", "НЕ" и создавать всплывающее окно с текстом подсказки или ошибки.

Пока получается, что у оператора нет никаких ограничений и защиты от дубликатов. А реализовать через ручной ввод (без выбора из списков) нецелесообразно. В My Visual Database это прекрасно реализовано, но в отличии от нее ваша система гибче и позволяет реализовывать хотелки на лету без глобальной перестройки всей логики.

[alcompstudio]

Здравствуйте. Имеется задача: Формируется заявка на определённую дату. В заявку из списка выбирается уникальный номер. Как запретить добавление записи, если дата и номер совпадают с уже имеющейся заявкой?

Добрый день!

Вы уникальные номера формируете где-то в списке каком-то? Это как? В принципе ж есть опция проверки на уникальность для поля

http://prntscr.com/r40bda - для текстового
http://prntscr.com/r40bnr - для чисолового

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

А в комплексе Автоинкремента с типами поля "Текст по шаблону" (динамическое поле) или "Статический текст по шаблону" (для записи в БД и поиска по этому полю) - вы можете формировать произвольные "названия" номера, по типу

INV001-18.02.20

В поле Текст по шаблону такое выражение, например, можно составить: INV00[100]-[110], где 100 - это ID поля с типом Автоинкремент, а 110 - поле с типом Дата. Ну или в таком духе. При этом у вас не будут дублироваться номера заявок и в ручную не нужно будет выбирать их.

Если я, конечно, правильно понял суть вашей проблемы.

[triadax]

Здравствуйте. Имеется задача: Формируется заявка на определённую дату. В заявку из списка выбирается уникальный номер. Как запретить добавление записи, если дата и номер совпадают с уже имеющейся заявкой?

Добрый день!

Вы уникальные номера формируете где-то в списке каком-то? Это как? В принципе ж есть опция проверки на уникальность для поля

http://prntscr.com/r40bda - для текстового
http://prntscr.com/r40bnr - для чисолового

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

А в комплексе Автоинкремента с типами поля "Текст по шаблону" (динамическое поле) или "Статический текст по шаблону" (для записи в БД и поиска по этому полю) - вы можете формировать произвольные "названия" номера, по типу

INV001-18.02.20

В поле Текст по шаблону такое выражение, например, можно составить: INV00[100]-[110], где 100 - это ID поля с типом Автоинкремент, а 110 - поле с типом Дата. Ну или в таком духе. При этом у вас не будут дублироваться номера заявок и в ручную не нужно будет выбирать их.

Если я, конечно, правильно понял суть вашей проблемы.

Здравствуйте. У нас имеется сущность "Оборудование" в которой хранятся объекты с уникальным, инвентарным номером, моделью и датой ввода в эксплуатацию. У нас есть сущность "Прокат" в которой имеются поля: "дата начала проката", "дата окончания", "инвентарный номер" (выбирается из списка ajax) с заполнением поля "модель" и пр. По условию мы не можем выдать оборудование в один и тот же день. Поэтому необходимо проверять поля "дата начала проката" и "инвентарный номер" если запись есть, то выводить сообщение об ошибке и не давать записывать в базу.

[alcompstudio]

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

[triadax]

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

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

[support]

(выбирается из списка ajax)

Решением может быть доп опция для этого типа поля, где можно будет указать свое mysql условие для выборки данных, где вы можете просто скрыть оборудование, которое уже добавлено.
Такое решение я предлагал тут viewtopic.php?f=2&t=3055

[triadax]

(выбирается из списка ajax)

Решением может быть доп опция для этого типа поля, где можно будет указать свое mysql условие для выборки данных, где вы можете просто скрыть оборудование, которое уже добавлено.
Такое решение я предлагал тут viewtopic.php?f=2&t=3055

Ну это по большей части костыль. Хотелось бы выстраивать четкую логику и понимание процессов в самой системе на базовом уровне, а не подстраиваться под недостатки. Когда у Вас настроено большое число сервисов и бизнес-процессов, то рано или поздно придётся пожинать плоды всех этих недочетов. Плюс, человеческий фактор. Простым пользователям необходима "защита от дурака" и мое предложение о введении условий и всплывающих форм, надеюсь будет услышано. Так же хотелось бы видеть какую-то структуризацию сущностей, группировку, возможность сворачивать. У "Руководителя" огромный потенциал и хотелось бы чтобы он стал лучше.

[HakimzyanovA]

Когда у Вас настроено большое число сервисов и бизнес-процессов, то рано или поздно придётся пожинать плоды всех этих недочетов

Поддержу. Я здесь viewtopic.php?f=3&t=3034 уже предлагал внедрить похожий функционал.
Может быть подумать о механизме "событие"-"условие"-действие", на уровне сущности, аналогично триггерам SQL?
Например сейчас нечто подобное реализовано для поля "Этапы": к изменению значения поля можно привязать действие.

Cобытия: "новая запись", "редактирование", "удаление"
Условия: фильтр на значения полей, условие уникальности конкретного поля
Действия: запрет действия или действие из автоматизации или "показать уточняющий запрос да/нет" или "отправить письмо пользователю".
Список условий и действий можно постепенно дополнять, не обязательно все сразу

Например:
1. Можно решить задачу автора темы
2. Запрет ввода операций с датой не в операционном периоде, как я писал в предыдущей теме
3. Оформили заказ больше "Порог бонуса" рублей - показать окошко с напоминанием об оформлении бонусной карты
Можно еще сделать служебную сущность, в которой пользователь может заводить глобальные переменные, доступные для использования в условиях. Т.е. завел переменную "Порог бонуса" - 1000 руб.
ну и так далее.

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