Xrm.Page.context.getUserRoles()

[andyandy]

Всем доброго времени суток!

Написал небольшой код для определения наличия у пользователя нужной роли. Прогнал эту функцию на нескольких тестовых пользователях и после положительного результата впихнул на боевой сервер. И всё работало замечательно до тех пор пока не нашлось несколько пользователей, у которых эта функция не срабатывала. Добавил несколько алертов для того что бы понять что же там не так и обнаружил что у этих "избранных" пользователей в строке помеченной *** возвращается совершенно другое значения ID нежели на самом деле имеет эта группа. Назначал разные роли для этих пользователей и скрипт тоже возвращал какие-то другие значения. Похоже, что я упустил какой - то нюанс в этом коде, но хоть убей не пойму в чём он заключается...

function checkUserGroups(group/*группа в виде ID без фигурных скобок*/)//Проверка пользователя на участие в группе
{
	if (!group)
	{
		//alert ("Пусто!!!");
		return false;
	}
	var userroles;
	var result = false;
	userroles = Xrm.Page.context.getUserRoles();
	//alert (typeof userroles);
	group = group.toLowerCase();
	//alert (userroles);

	//alert (UserRoles[1]);
	for (var i=0; i<=userroles.length; i++) {
		//alert ("Сейчас сравним правильную группу: \"" + group + "\" сравним со значением из массива: \"" + userroles[i]+"\"");
		if (userroles[i]) {
		//alert( "Обнаружена роль: " + userroles[i].toUpperCase()); //***
		if (userroles[i] == group) {
			//alert("Правильная роль обнаружена!" + userroles[i].toUpperCase());
			result = true;
			return result;
		}
	}
	}
	//alert ("Результат проверки группы '"+group+"' != "+ result);
	return result;
}

[slivka_83]

Пользователи из разных подразделений?

[andyandy]

Так точно, в разных!
Не думал, что проблема может быть в этом . Получается нужно добавлять сразу несколько ID для каждого подразделения... Попробую спасибо за быстрый ответ.

[Roman08]

Цитата:

Сообщение от andyandy

. Получается нужно добавлять сразу несколько ID для каждого подразделения... .

Если подразделения наследуют роль из родительского, то роли с одинаковыми названиями создаются во всех дочерних подразделениях. Чтобы на хардкодить гуиды, мы в тех. условиях с заказчиком оговорили названия ролей, которые не должны изменяться, и уже в коде используем эти названия. Решение тоже не 100% элегантное, но перенос кода осуществляется легче.

[andyandy]

Всё заработало спасибо! С названиями интересный вариант, но мало ли кто нибудь его изменит в моё отсутствие и забудет об этом упомянуть . Хотя я так понимаю 100% гибкого решения не придумаешь...

[Артем Enot Грунин]

Я в своем решении хардкодил только идентификаторы головных ролей (считайте ролей в головном подразделении). Далее скриптом запрашивал ParentRootRoleId от ролей пользователя и сравнивал с хардкодом.

Еще есть вариант стразу запросить рутовые роли текущего пользователя через OData: /SystemUserRolesSet?$select=systemuserroles_association/ParentRootRoleId&$expand=systemuserroles_association&$filter=SystemUserId eq guid'sample', но у меня так не вышло. Через SOAP не пробовал, но там точно должно работать.

[g.Naukovych]

Мы решаем проблему следующим образом.

у нас есть специальная сущность "Настройка", где есть уникальный строковый идентификатор, по которому эту настройку можно найти и поле значение

в поле значение мы через разделитель задаем названия ролей

в коде, получаем значение, разбиваем на массив ролей и выполняем проверку.

если название роли будет изменено, то достаточно изменить его в настройке и не менять код

особенно полезно, когда неожиданно функционал должен быстро начать работать и для другой роли