CRM Руководитель - Форум

Ведь это вполне стандартная возможность для правильного софта.

Хотелось бы увидеть пример, как это реализовано в правильном софте.

Хотелось бы увидеть пример, как это реализовано в правильном софте.

Я говорил о том, что "правильный софт" должен иметь защиту от ошибок пользователя, потому что пользователь ошибается всегда, даже там, где это невозможно.
Например, пусть есть форма, на которой заполняется две даты - дата рождения и дата приема на работу.
Валидатор даты рождения должен проверить, что она к примеру не ранее 1940 года.
Валидатор формы после заполнения всех полей на форме должен проверить, что дата приема на работу больше даты рождения как минимум на 14 лет.
Чем сложнее логика приложения - тем больше необходимости в валидаторах.
Можно оставить это на совести того, кто вводит данные - но со временем в БД неизбежно накопится куча подобных ошибок со всеми вытекающими. И да - многие разработчики именно так и поступают, не заморачиваясь... Я считаю это категорически неверным, и хотелось бы, чтобы ваш замечательный софт в этом плане был "правильным".

Выскажу сугубо личную точку зрения

Руководитель - это не специализированная система, "заточенная" под конкретную задачу, а универсальный конструктор. Как следствие, вся адаптация к конкретной предметной области ложится на того, кто из этого конструктора делает готовое приложение - на разработчика приложения

В частности, для Руководителя поле Дата - это только дата и ничего более. Руководитель совершенно четко проверяет правильность ввода даты, но он не может знать, это дата рождения сотрудника или дата запуска первого спутника.

Есть также поле ввода по маске, которое призвано свести к минимуму ошибки

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

Так я об этом и говорю же! Нужно в настройки полей и формы добавить механизм вызова валидаторов.
Ну, например у каждого поля появляется еще два дополнительных атрибута: начальное значение и валидатор.
В атрибут "начальное значение" заносим php-код, который возвращает искомое.
В поле "валидатор" - php-код, который возвращает true/false.
Аналогично и для валидатора формы.
Это ведь технически возможно сделать?
Естественно, заполнять (или оставлять пустыми) эти поля должен пользователь системы, исходя из конкретной бизнес-логики приложения, ибо он и только он точно знает, где дата рождения, где дата приема на работу и как они связаны.

P.S. Ребята, механизм встроенных валидаторов успешно юзался еще в Clipper 20 лет назад... Ну не приводить же мне в пример свою курсовую по курсу "Разработка БД" А за отсутствие таковых - выше тройки нам не ставили.

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

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

Описанный вами механизм противоречит концепции системы Руководитель.

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

В Руководителе пользователь нигде не пишет код в явном виде, пользователь даже не знает, на каком языке разработан Руководитель

Это инструмент не для пользователя, а для администратора системы.

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

Для этого есть ограничения прав доступа к администрированию системы. И не хотите использовать - оставьте данные поля пустыми, и все. Как именно технически реализовать механизм валидаторов - вопрос обсуждаемый. Не подойдет php - ok, пусть будет просто формула либо выражение из полей, возвращающее true/false.

Если у Вас есть альтернативное решение обеспечения контроля правильности ввода данных и непротиворечивости БД на уровне бизнес-логики - хотелось бы выслушать.

P.S. Предлагаю добавить механизм в дополнение - будет лишний стимул купить продукт

Что касается конкретного примера:

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

То такие проверки считаю нужными и нужно попробовать их ввести.
Добавил в план, посмотрим что получится.

Добавил в план, посмотрим что получится.

Сергей, получается что-нибудь на эту тему?
И еще где-то в планах была LDAP-авторизация с синхронизацией пароля в Руководитель при изменении пароля пользователя в домене...

Еще не приступал к этому функционалу. Сейчас работаю над публичными формами, затем API...