Как сделать View?

  • Автор темы rm2005
  • Дата начала
M

morpheus

Для: rm2005
Вам собственно надо обычная база заявок

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

а так

Ну зделайте
1.база где лежат заявки(назовем ее "З")
2.общий справочник(названия ресурсов, видов подключения , пользователей и т.д. )(назовем ее "С")
3. в базе З зделать виды с заявками категоризированными по имени пользователя.. или же просто имена пользователей , а в карточке пользователя ввести вложенное представление в котором отображаються все заявки от него поступившие
4. зделать парочку видов .. вроде Актуальные заявки, просроченные, архив, отклоненно и т.д.
 
R

rm2005

Это понятно. Суть программы в том что-бы можно было просмотреть ресурсы по каждому пользователю. Причем сотрудник может видеть свои ресурсы, начальник должен видеть все ресурсы своих сотрудников. СБ и админы всех. Т.е. заявка - есть промежуточный документ, нужный только на стадии ее согласования, далее он не нужна, если только для истории.

Как базы организовать проблем нет. Вся проблема как сделать интерфейс пользователя с учетом специфики Lotus.
 
K

K-Fire

<!--QuoteBegin-rm2005+27:12:2006, 12:14 -->
<span class="vbquote">(rm2005 @ 27:12:2006, 12:14 )</span><!--QuoteEBegin-->Это понятно. Суть программы в том что-бы можно было просмотреть ресурсы по каждому пользователю. Причем сотрудник может видеть свои ресурсы, начальник должен видеть все ресурсы своих сотрудников. СБ и админы всех. Т.е. заявка - есть промежуточный документ, нужный только на стадии ее согласования, далее он не нужна, если только для истории.

Как базы организовать проблем нет. Вся проблема как сделать интерфейс пользователя с учетом специфики Lotus.
[snapback]51880" rel="nofollow" target="_blank[/snapback]​
[/quote]

Такую задачу можно реализовать следующим образом:
1) Создаете базу-справочник сотрудников. В ней в иерархическом виде прописаны отделы и их сотрудники.
2) Создаете базу "Заявки". При создании документа заявки и при выборе сотрудника, прописываете права доступа:
-- автора добавляете в авторское поле
-- сотрудника для которого заявка - в ридерское
-- начальника сотрудника - в ридерское
-- СБ и админов в ридерское (или авторское если нужно)
Ну или чуть иначе в зависимости от того что вам нужно.
3) Настраиваете ACL, обычным пользователям ставите уровень доступа Author.

Вот собственно и все, каждый пользователь будет видеть только те документы которые ему нужно видеть.

Да, кстати, в такой схеме необходимо обязательно в каждый документ добавить авторское поле с некоей ролью [Admin]. И в ACL администратору ставите эту роль. Тогда вы избежите ситуации когда в базе есть документы, а их никто не видит. Такая ситуация легко может возникнуть наример при отладке приложения.
 
O

oshmianski

Для: K-Fire
Я бы пробовал использовать группы, ведь начальники и "сильные мира сего" меняться могут.
 
R

rm2005

Для: oshmianski
Предполагается что справочник сотрудников будет формироваться динамически из 1С и каждому пользователю по ФИО будет сопоставляться Notes-имя. Поэтому группы не пойдут, так как их придется править в ручную
Для: K-Fire
Предполагается, что будет большое количество заявок, большое количество пользователей, я предполагал сделать иерархический вид (по-фамильный) определённого отдела, где в подразделах будет видно, какими ресурсами обладает пользователь.
 
K

K-Fire

<!--QuoteBegin-oshmianski+27:12:2006, 15:25 -->
<span class="vbquote">(oshmianski @ 27:12:2006, 15:25 )</span><!--QuoteEBegin-->Я бы пробовал использовать группы, ведь начальники и "сильные мира сего" меняться могут.
[snapback]51924" rel="nofollow" target="_blank[/snapback]​
[/quote]

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

По отдельности разберу:

<!--QuoteBegin-rm2005+27:12:2006, 15:41 -->
<span class="vbquote">(rm2005 @ 27:12:2006, 15:41 )</span><!--QuoteEBegin-->Предполагается, что будет большое количество заявок, большое количество пользователей.
[snapback]51930" rel="nofollow" target="_blank[/snapback]​
[/quote]

Замечательно, если заявок не больше 1 миллиона то проблем не вижу.

<!--QuoteBegin-rm2005+27:12:2006, 15:41 -->
<span class="vbquote">(rm2005 @ 27:12:2006, 15:41 )</span><!--QuoteEBegin-->я предполагал сделать иерархический вид (по-фамильный) определённого отдела, где в подразделах будет видно, какими ресурсами обладает пользователь.
[snapback]51930" rel="nofollow" target="_blank[/snapback]​
[/quote]

А вот тут объясните, что значит иерархический вид (по-фамильный) ? И зачем вообще иерархия нужна там?

<!--QuoteBegin-rm2005+27:12:2006, 15:41 -->
<span class="vbquote">(rm2005 @ 27:12:2006, 15:41 )</span><!--QuoteEBegin-->где в подразделах будет видно, какими ресурсами обладает пользователь.
[snapback]51930" rel="nofollow" target="_blank[/snapback]​
[/quote]

Что за подразделы? Непонятно :)

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

rm2005

Всё! Вроде бы вкурил. Воспользовался вашем советом. Сделал категоризированную вьюху по сотруднику и отделу. Вроде всем понравилась.
У меня ещё пару вопросов, если можно?

1) Как обойти проблему переименования отделов? Присвоить всем отделам код или воспользоваться UNID? А как тогда во вьюхах вместо него наименование вставлять?

2) группы в ACL, я так понял создавать автоматически при создании отдела и добавлять в нее пользователей и все группы ниже по иерархии?
И группу отдела прописывать в поле Readers?
 
O

oshmianski

rm2005 сказал(а):
...
1) Как обойти проблему переименования отделов? Присвоить всем отделам код или воспользоваться UNID? А как тогда во вьюхах вместо него наименование вставлять?
...
Нажмите, чтобы раскрыть...
А никак. Лотус нереляционка, ну нету здесь ссылочной целостности. Все ручками делать нужно. Изменили название, пробегаешь по всем зависимым докам и правишь.
 
R

rm2005

Для: oshmianski
Ужас. А как тогда лучше это сделать? При смене названии? А если там 1000 и больше документов, то займет кучу времени. Если только где-то сохранять старое наименование и агентом например ночью менять? Как принято это делать?
 
M

morpheus

да, ночным агентиком
1000 документов...это не так уж и много
 
O

oshmianski

rm2005 сказал(а):
Для: oshmianski
Ужас. А как тогда лучше это сделать? При смене названии? А если там 1000 и больше документов, то займет кучу времени. Если только где-то сохранять старое наименование и агентом например ночью менять? Как принято это делать?
Нажмите, чтобы раскрыть...
1000 - это мелочь, поверте. делаю так, как сказал. других способов не знаю. если кто подскажет, буду рад.
 
M

morpheus

Для: oshmianski
А это уже регламентом на предприятии решаеться :)
раз изменилось имя, значит в течении N ней поменять и т.п.
не думаю что они кажный день там имена отделов меняют
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!

Верх Низ