| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			Поможет ли RLS?
			 
			
			Добрый день всем. 
		
		
		
		
		
		
		
	Возникла задача ограничить доступ определенной группы пользователей к определенным складам при создании Заказа на продажу. Т.е. сделать так, чтобы определенные склады нельзя было выбрать в lookup форме при создании нового заказа. Однако, в Отчеты-Запросы-В наличии на складах нужно эти склады видеть.  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			если выпадающих списков, которые надо фильтровать, не много (1-2-3), то проще перекрыть соответствующие lookup'ы и наложить фильтр там
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Prophetic (1). | |
| 
			
			 | 
		#3 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Поможет отфильтровать список складов в такой постановке задачи. Но, возможно, что где-то такое решение вылезет боком. 
		
		
		
		
		
		
			В ряде версий и СП невидимое в лукапе из-за RLS значение можно ввести вручную, если вы его знаете, и система не ругается. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Prophetic (1). | |
| 
			
			 | 
		#4 | 
| 
			
			 Боец 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Цитата: 
	
Пусть Б - таблица-приемник, куда вбивается значение из лукапа, на неё RLS не настроен. Вполне предсказуемо, что в таблицу Б мы можем ручками вбить запрещенное значение (только такое поведение я и встречал). С другой стороны, система должна запрещать вручную вбивать значение, отсутствующее в лукапе. Т.е. для надежности - впервую очередь RLS должен быть настроен на таблицу Б (но таких таблиц, где м.б. ссылка на А в системе м.б. много...). Glibs, а в каких версиях система не дает ручками вбить в таблицу Б? В 3-ке и 4-ке дает... Ест Последний раз редактировалось DSPIC; 24.03.2010 в 22:58.  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Prophetic (1). | |
| 
			
			 | 
		#5 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Если не ошибаюсь, glibs имел в виду следующую особенность поведения системы : 
		
		
		
		
		
		
		
	Если в вашем примере настроен RLS на табличку Б то для одних билдов система просто накладывала дополнительный фильтр на табличку Б при просмотре, не запрещая создавать руками значения противоречащие RLS (т.е. RLS действовал исключительно как фильтр при просмотре), а в других билдах - запрещала. Т.е. RLS действовал не только как фильтр, но и накладывал ограничения на значения в поле. Т.е. RLS влиял на валидацию значений. На каком варианте в итоге остановились - не помню. Можно протестировать по последнему билду.  | 
| 
	
 | 
|
| За это сообщение автора поблагодарили: Prophetic (1). | |
| 
			
			 | 
		#6 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от DSPIC
			
			 
И пользователи этой группы запрещенных складов ни в одном лукапе не увидят во всей системе...  
		
	Цитата: 
	
		
			Сообщение от DSPIC
			
			 
... 
		
	Вполне предсказуемо, что в таблицу Б мы можем ручками вбить запрещенное значение (только такое поведение я и встречал). С другой стороны, система должна запрещать вручную вбивать значение, отсутствующее в лукапе. ... Цитата: 
	
		
			Сообщение от DSPIC
			
			 
... 
		
	а в каких версиях система не дает ручками вбить в таблицу Б? В 3-ке и 4-ке дает... ... Только что проверил 3.0 сп6 с ядром от KR3. Эффект воспроизводится. 5.0 сп2 hotfix rollup 3. Эффект воспроизводится. Вообще, насколько я помню историю RLS, то в 2.5 был партнерский модуль, и не помню точно, не было ли путей его обойти. В 3.0 появился в базовой поставке, но работал нестабильно (с критическим количеством багов) до сп3. Позже в каком-то из последних СП таки встроили RLS и в validateField() в ядре где-то. Писали где-то, но не могу найти, что в 4.0 это сломали, и проверка поля опять перестала работать. Не помню, проверял или нет. В 5.0 вроде починили. С какого СП — не помню. Может кто сможет дополнить чего в истории. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Administrator 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
а) позволял ввести запрещенное значение б) При попытке фильтрации по полю, на который был наложен фильтр с пустым значением - естественным образом сбрасывал фильтр, в результате чего пользователь мог видеть все записи (т.е. права не работали) Сделанный RLS (и это важно) работал именно в ядре. Т.е. уже никакой фильтр по пустому значению не мог его сломать. Равно как и вводить запрещенное значение. 
				__________________ 
		
		
		
		
	Возможно сделать все. Вопрос времени  | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
		
			Сообщение от Logger
			
			 
... 
		
	Если не ошибаюсь, glibs имел в виду ...  .Уточню на примере, чтобы не возникало ни у кого разночтений. Я тестировал на таблицах LedgerTable и LedgerBudget. На плане счетов настроил RLS как !ХХХ, где "ХХХ" — некий счет ГК. Натравил этот RLS на пользователя через группы. Убедился, что в плане счетов счет "ХХХ" не отображается. Убедился, что в лукапе счетов ГК в бюджетных проводках счет "ХХХ" не отображается. При создании бюджетной проводки ввел значение "ХХХ" в соответствующее поле и попытался его покинуть, на что получил сообщение что значение "ХХХ" отсутствует в таблице План счетов. Вообще было очень прискорбно, когда такого эффекта удалось добиться для 3.0, но он был потерян в 4.0. Есть гипотеза, что в 3.0 этот функционал сделали после того, как разработчики ядра 4.0 отделились вместе с наследием для разработки новой версии. Мне все кажется, что в 3.0 такое поведение появилось с сп5. Что касается описанного вами случая... IMHO сейчас эффект корректный. Если бы я настроил RLS на таблицу бюджетных проводок по счету ГК, то создать я строчку могу, а вот когда открою форму снова, то уже не увижу созданную мною же запись. Не вижу ничего некорректного в том, что проверка значения поля делается по RLS на справочнике, а не по фильтру на транзакционной таблице. Первое, IMHO, логичнее. Если нужно запретить и видеть и создавать записи по значению справочника в транзакционной таблице — фильтр настраивается два раза: и на справочнике, и на транзакционной таблице. А именно ввод значения — справочник. В результате можно выбирать между первым, вторым и первым и вторым одновременно. Обратил внимание, что настройка RLS в 5.0 у меня не заработала, пока я входил в группу "Admin". На более ранних версиях я такого не замечал. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
| 
			
			 | 
		#9 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Принял решение поступить по совету glibs: в моём простом случае фильтр решил проблему.  
		
		
		
		
		
		
		
	Благодарю всех откликнувшихся.  | 
| 
	
 | 
| 
	
	 | 
	
			 
			Похожие темы
		 | 
	||||
| Тема | Ответов | |||
| Что делает RLS с связанными запросами в отчете | 8 | |||
| Gustav: Unsorted, или Записки DAX-дилетанта - II | 39 | |||
| Особенности настройки RLS на склад | 0 | |||
| RLS глюк? | 11 | |||
| Проблема с RLS и SecurityKey. | 3 | |||
| Опции темы | Поиск в этой теме | 
| Опции просмотра | |
		
  |