Есть документ организация (поле fORG), есть документ сотрудник (ref к организации) поля: pFIO, pORG, есть документ событие (ref к сотруднику) поля :eStart, eEnd, eFIO,eORG. Вопрос в том, как мне сделать так что бы при изменении имени сотрудника во всех документах "события" тоже были новые значения. Если я сохраняю в документе не имя сотрудника а unid, то как мне потом во вьюхе отображать Имя пользователя а не unid?? Событий будет много. Ну и с организацией то же самое, просто не понимаю как связать это все ) ???
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Тебе писали... учи классику... базовые методы и функции.
Во view толстого клиента - никак. Там нужны статические значения.
В web - можно. В SSJS добавлены некоторые функции @formula. Жаль этой нет @GetDocField( documentUNID ; fieldName )
WEB вообще достаточно гибкий. Просто немного подумать надо
В свойстве колонки вида можно делать практически что угодно. Дальше берешь документ по юниду и вперед
Если нужна категоризация по организации - то нужны статические данные подразделений в документах. В общем все зависит от задачи...
А как решаются подобные задачи в толстом клиенте, как вообще связываются данные??
Можешь подсказать еще что такое rowData )? И что за значения должны быть в pOrg имя организации или ID fOrg ???
Такие вещи, как названия организаций и ФИО сотрудников, заносятся во все связанные документы (для отображения в видах), при изменении данных в справочнике они меняются фоновым агентом во всех документах. Это классический вариант.
Другое дело, что я с трудом представляю себе задачу, при которой данные справочников меняются постоянно...
Есть ссылка на пример ? Просто не догоняю чутка как искать документы где изменилось фио или организация, а потом еще и менять это в других документах, причем же ФИО у разных людей может быть одинаковое (
Нужно не постоянно, а оперативно, пользователь не может ждать пока на следующий день ночью фоновый агент их поменяет, ему нужен измененный документ сразу.
Навскидку. В каждом рабочем документе сохраняем ФИО человека и его уникальный ID (ID генерится при создании человека а справочнике). Агент проверяет дату модификации документов справочника, при ее изменении отбирает все рабочие документы, в которых указан ID человека и заменяет ФИО. Ну ессно, желательно проверять, что именно изменилось (и изменилось ли реально - ведь документ можно просто пересохранить, не меняя значения полей) в документе справочника, дабы не обновлять рабочие документы попусту.
чтоб строить проверку - надо знать как будет изменяться документ.
Но в любом случае - куда-то сохраняешь старые значения, а потом перед/после сохранением проверяют старые и новые значения.
Тут не подскажешьТебе писали... учи классику... базовые методы и функции.
Во view толстого клиента - никак. Там нужны статические значения.
В web - можно. В SSJS добавлены некоторые функции @formula. Жаль этой нет @GetDocField( documentUNID ; fieldName )
WEB вообще достаточно гибкий. Просто немного подумать надо
Посмотреть вложение 6190 Посмотреть вложение 6191
Если нужна категоризация по организации - то нужны статические данные подразделений в документах. В общем все зависит от задачи...
, что за значения должны быть в pOrg имя организации или ID fOrg ???
рекомендую начать с самого начала и с обычного клиента.
Практика практикой, но теорию почитать надо.
Рекомендую посмотреть на дизайн существующих баз.
И пробовать с самого простого. Если пытаешься применить "нормальные формы" к посторению БД в лотусе - забудь. По крайней мере для толстого клиента.
На WEB можно попробовать сделать все по правильному.
- Для иерархии подразделений (если есть документы подразделений) и сотрудников - достаточно в каждом подразделении содержать только название подразделения, а в карточке сотрудника ничего не надо. Ну и конечно же иерархия по респонсам.
- Для иерархии ТОЛЬКО сотрудников - в карточке сотрудника должен быть полный путь подразделений через \
- Для иерархии твоих заданий, которые привязаны к персонам - надо хранить и ФИО сотрулника и его полное подразделение. Т.к. построить вид только по сотруднику и его заданию не получится, т.к. сотрудник сам по себе респонс., а вид для иерархии должен начинаться с документа, а не респонса.
Так что наверное проще всего - держать в документе задания все необходимые значения и писать агент, который все актуализировать будет.
Практика практикой, но теорию почитать надо.
Рекомендую посмотреть на дизайн существующих баз.
И пробовать с самого простого. Если пытаешься применить "нормальные формы" к посторению БД в лотусе - забудь. По крайней мере для толстого клиента.
На WEB можно попробовать сделать все по правильному.
- Для иерархии подразделений (если есть документы подразделений) и сотрудников - достаточно в каждом подразделении содержать только название подразделения, а в карточке сотрудника ничего не надо. Ну и конечно же иерархия по респонсам.
- Для иерархии ТОЛЬКО сотрудников - в карточке сотрудника должен быть полный путь подразделений через \
- Для иерархии твоих заданий, которые привязаны к персонам - надо хранить и ФИО сотрулника и его полное подразделение. Т.к. построить вид только по сотруднику и его заданию не получится, т.к. сотрудник сам по себе респонс., а вид для иерархии должен начинаться с документа, а не респонса.
Так что наверное проще всего - держать в документе задания все необходимые значения и писать агент, который все актуализировать будет.
Джонни, заканчивай с хпагесами, СМС-ками и т.д. Учи классику. Тебе, уже, не один человек об этом сказал.
"\"-это "разделитель" при отображении в категоризированной колонке.
Пойми уже, что Доминоха, это не Джумала и остальная фиготень, где можно ничего не зная делать сайты. Доминоха это достаточно серьёзная система, требующая от человека знания её архитектуры + крайне жалательно знания всех "глюков" (особенностей и т.д.). Не зная основ и глюков человек превращается в говнокодера, коих просто тьма. Вон, одного говнокодера уволили две недели назад. до сих пор разгребаю его говно. Провалы в элементарных знаниях, приводит к тому, что задваиваются (да что там задваиваются, за 3700-ряются) документы, которые обязаны быть уникальными (и это, за 2-ва года, человек, так и не запомнил как работают вьюхи... при этом оригинальная база 800мб против 80мб переделанной. Документы 151т. (и это, оптимизированно на ходу, когда базу получил в руки, там под 400т. было. 151т. это максимум до которого можно урезать, без потери связей с другими базами) против 30т.). При этом всём, в "оригинале" допущены ошибки в "основах", которые блокируют дальнейшее развитие базы (а сейчас, для неё, только "старт"), при этом, новая версия с 30т. документами значительно меньше, быстрее, правильней и, самое главное, служит для дальнейшего развития системы. За две недели моей работы, в первые три дня, я закрыл 99% проблем, которые не смог закрыть говнокодер за 3-ри месяца. В данный момент осталась только одна проблема (из известных) это обновление данных из SQL (именно обновление, а не первоначальный импорт или дополнение). За сегодня данную проблему, думаю, доделаю. Итого, за две недели, я почти сделал систему, которую, более чем за три месяца не смог сделать говнокодер. Как тебе разница по времени/функционалу/проблемам?
"\"-это "разделитель" при отображении в категоризированной колонке.
Пойми уже, что Доминоха, это не Джумала и остальная фиготень, где можно ничего не зная делать сайты. Доминоха это достаточно серьёзная система, требующая от человека знания её архитектуры + крайне жалательно знания всех "глюков" (особенностей и т.д.). Не зная основ и глюков человек превращается в говнокодера, коих просто тьма. Вон, одного говнокодера уволили две недели назад. до сих пор разгребаю его говно. Провалы в элементарных знаниях, приводит к тому, что задваиваются (да что там задваиваются, за 3700-ряются) документы, которые обязаны быть уникальными (и это, за 2-ва года, человек, так и не запомнил как работают вьюхи... при этом оригинальная база 800мб против 80мб переделанной. Документы 151т. (и это, оптимизированно на ходу, когда базу получил в руки, там под 400т. было. 151т. это максимум до которого можно урезать, без потери связей с другими базами) против 30т.). При этом всём, в "оригинале" допущены ошибки в "основах", которые блокируют дальнейшее развитие базы (а сейчас, для неё, только "старт"), при этом, новая версия с 30т. документами значительно меньше, быстрее, правильней и, самое главное, служит для дальнейшего развития системы. За две недели моей работы, в первые три дня, я закрыл 99% проблем, которые не смог закрыть говнокодер за 3-ри месяца. В данный момент осталась только одна проблема (из известных) это обновление данных из SQL (именно обновление, а не первоначальный импорт или дополнение). За сегодня данную проблему, думаю, доделаю. Итого, за две недели, я почти сделал систему, которую, более чем за три месяца не смог сделать говнокодер. Как тебе разница по времени/функционалу/проблемам?
Обучение наступательной кибербезопасности в игровой форме. Начать игру!