Есть вот такая ситуация:
заказчик захотел, чтобы доступ к справочнику клиентов разграничивался по вертикали. Тоесть пользователи подразделения А не видели и даже не догадывались о клиентах подразделения В.
Складывается пренеприятнейшая ситуация с общими клиентами - когда пользователь создает клиента, а при вставке записи мы обнаруживаем, что такой клиент уже есть, но у этого пользователя к нему нет доступа....
Кроме варианта посоветовать пользователю обратиться в соседний отдел за правами доступа, в голову ничего не приходит, но тогда права доступа теряют всякий смысл - достаточно всего-лишь тупо пытаться добавить клиента и получать отказ в доступе, чтобы узнать, что такой клиент есть и он является клиентом соседнего подразделения... Заказчика убедить в комичности и нелогичности ситуации не получается. :-(

Может кто подскажет дельную мысль?

sergey888Пара вопросов:
1.Каким образом осуществляется разграничение прав доступа
2.Кто имеет право добавлять клиентов.

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

1.разграничение осуществляется просто - есть еще одна табличка:
UserID int
ClientID int
IsView bit
IsEdit bit
IsClose bit
соотетственно, при выводе списка клиентов идет джоин к этой таблице с выборкой по текущему пользователю и флагу, соответствующему данной операции.

2.Клиентов добавлять может любой менеджер.

2 softwarer:
спасибо за дельные мысли. в принципе, работа с клиентами ведется очень хитро - балансы подбиваются по подразделению, но клиент может прислать деньги на разные подразделения одним платежом - есть отдельный человек, который потом разносит эти деньги по подразделениям. Соответственно, запись должна быть одна...
Хотя мне очень понравилась мысль с двумя разными записями....с небольшой добавкой - они должны иметь хотя-бы ссылку друг на друга, тогда в принципе если что, можно будет свести и общий баланс и сделат ьперезачет денег между подразделениями.
Наверно етак и сделаем - спасибо за наводку!

sergey8882 записи на одного контрагента - не советую. Лучше все-таки подумать об организации прав доступа.
А если появится еще 2-3 группы пользователей, то в таблице будет 4-5 записей для одного конрагента? Бред.
да, бред - мы тут внутри уже пришли к такому заключению. Бредовая постановка приводит к бреду в реализации...
пока думаем в направлении поиска аргументов чтобы разубедить заказчика в таком подходе. Пока стоим на том, что разграничивать надо не справочники, а движения.

guest_20040621> тогда права доступа теряют всякий смысл

Конечно, нет.

> такой клиент есть и он является клиентом соседнего подразделения

А зачем отдавать такие данные всем желающим?

> Заказчика убедить в комичности и нелогичности ситуации не получается.

Требование заказчика в данном случае - абсолютно уместно. Ничего комичного.

> Может кто подскажет дельную мысль?

Из Вашего описания - два источника проблем. Первая проблема: логическая модель доступа; попросите заказчика уточнить, на каком уровне детализации (контрагент, подразделение контрагента, персонал подразделения контрагента) какие ограничения доступа нужны. Вторая проблема: собственно модель бизнеса заказчика. Imho невероятная тупость - не координировать деятельность своих сотрудников.
дело в том, что там подразделения - весьма далеки друг от друга, это холдинг, со всеми вытекающими.

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

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

iscrafm2 Hibernate
--
А что Вам мешает к клиенту привязать список подразделений(сотрудников), которым разрешен доступ. При создании новой записи в контрагентах ее автор прописывается автоматом, остальным разрешения раздаются путем добавления в список. Автора можно записывать непосредственно в запись клиента. Показываются записи автора + все у которых он есть в списке разрешений.
дело в другом, задача тоньше - подразделение А никаким образом не должно узнать, что клиент является или являлся клиентом другого подразделения.

guest_20040621

> а вот всякие там контакты, финансовая инфа - отдельно по подразделению,
> и по правам доступа.

Imho напрасно.
почему, если не секрет?

bas iscrafm2 Hibernate
--
А что Вам мешает к клиенту привязать список подразделений(сотрудников), которым разрешен доступ. При создании новой записи в контрагентах ее автор прописывается автоматом, остальным разрешения раздаются путем добавления в список. Автора можно записывать непосредственно в запись клиента. Показываются записи автора + все у которых он есть в списке разрешений.

+1. При чем разрешения могут быть не простые, а с атрибутами баланса и т.д.
я о другом. вот сотруднику отдела А надо узнать, является ли "Рога и копыта" клиентом отдела В. По сути ему достаточно попытаться создать этого клиента в БД - по ее реакции можно получить ответ на поставленный вопрос.