Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

подскажите что нужно сделать чтобы ассоциировать новое ФИО этого юзера со всей старой информацией о ФИО которая фигурирует в базе уже миллион раз??? и все проверки идут именно по ней.
ID средствами Лоции можно оставить - но вот как быть с атрибутами...

кто-нибудь решал этот вопрос?
- проще завести нового юзера с новым фио и работать с двумя логинами сразу пока текущая работа по первому логину закончится?
- или не заморачиваться вообще - в надежде что юзер разведется и вернет ФИО на место?

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

один то один - но как-то в самом начале - мы проверки на разрешение работы с тем или иным объектом в нашем случае (менеджеры которые могут работать с конкретным клиентом) проверялись именно по ФИО а не по ID - т.к. база достаточно большая и прописано миллион фамилий (у каждого клиента от 1 до 5ти) - то при смене ФИО человек окажется вне списка разрешенных...
(чеж они замуж то не повыходили на этапе внедрения!!!)
так что если только список исключений формировать - но по моему тож не выход...
в общем засада полная

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

с группами наверно не получится - есть например 20 000 клиентов - соответственно делать 20 000 групп, тоже не выход. ФИО использовали для наглядности - зашел посмотрел кто может работать в виде форматированного текстового поля и все, заодно и проверка и изменения.
а ком действительно пойдет - наверно проще будет постепенных переход на текстовое поле из ID юзеров с восстановлением фамилий для просмотра на формах и в отчетах...
пока думаю.... но спасибо за ответы

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

Тогда у тебя наконец-то появится настоящее workflow

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

да, мы тоже переименовываем юзера. ИД остается тот же, а ФИО - меняется.. но у нас тоже есть некоторые проверки именно по ФИО, так что иногда это всплывает. но старых хвостов у нас ограниченное кол-во, поэтому мы при необходимости меняем ФИО со старого на новое у нужных объектов (таких объектов немного и они быстро заканчиваются).
но если хранить ИД вместо ФИО - то и такой проблемы не будет, это да..
а у вас что где конкретно прописано? в какой момент начинаются проблемы? можно поподробнее? если конечно вопрос еще актуален

Александр писал(а):да я говорил - посмотри говорю за кого ты выходишь - он же крокодил..

Любовь зла...

вопрос актуален... решим постепенно
1. ФИО прописано у нас в 90% объектов
2. Действий с проверками около 50'ти - но честно говоря я уже не помню как они называются куда привязаны и т.д.... т.е. надо проверять все
3. Отчетов с использованием этого ФИО - вроде немного не больше 10'ка
но пока все дело в том что все эти изменения мне нужно провести в один день - поскольку все используют всё
вот это меня пока и пугает

Могу предложить оригинальный выход.
У вас фамилии записанны в атрибуте объекта?
Если да - заходишь в значения атрибута и меняешь там фамилию
автоматически она меняется на всех объектах.
Но это пройдет только если фамилии присутствуют только на объектах.

да- если-бы только одна ФИО, а у нас там в значении разные списки из ФИО с указанием когда добавлен и кто по статусу... так что мы надежно зашифровались - на все 100!!!

через базу было бы конечно вообще быстро и просто
но если в атрибутах - не просто Фамилия И.О., а что то еще, то этого будет недостаточно.
с другой стороны, если ФИО только в атрибутах, то можно в конце концов сделать или действие, которое будет менять одно ФИО на другое в строковом атрибуте (хоть через globalreplace) и запустить его на подборке объектов, отобранных по значениям атрибутов или сиквел-скрипт, который будет делать то же самое, но в таблице value_string..
если ФИО забита в отчетах - то может быть можно и в отчетах поменять через базу, если понять, где что хранится.
то же самое - если в действиях зашито.. все функции (по крайней мере, которые не скрипты) действий хранятся в БД в чистом виде (насколько я понял)
а вообще... проблема, конечно серьезная.. у нас вроде как то удалось этого избежать.. чудом

Мда-а-а... Надо переходить на ссылки на объекты сотрудников. Записал в атрибут код объекта, а потом что хочешь, то и делай с этим сотрудником. Замуж выдавай, пол меняй, увольняй... Зато можно к этому объекту сотрудника привязывать объектики-изменения. Типа текущая фамилия появилась 21 марта 2007 года после выхода замуж. А предыдущая была такой-то.
Теоретически, можно поковырять базу на предмет глобальной замены и в действиях. Если value_string поменять легко, то синтаксис действий и отчетов нужно выковыривать контекстным поиском. Если не изменяет память, Александр в свое время подменял синтаксис форм для выпадающих списков. Здесь, похоже аналогичная ситуация. А уже после этого я бы озадачился переделкой на ссылки. Не претендую на истинное знание, наверняка и здесь есть подводные камни.

Старик Крупский писал(а):Зато можно к этому объекту сотрудника привязывать объектики-изменения. Типа текущая фамилия появилась 21 марта 2007 года после выхода замуж. А предыдущая была такой-то.

Можно просто историю значений атрибутов смотреть.