Перейти к содержанию
Сайт в скором времени будет закрыт, спасибо что были с нами! ×

Ограничения администратора

В большинстве случаев, вы должны поддерживать Ограничения администратора в классах ваших моделей, поскольку Invision Community существует возможность предоставления ограниченного функционала админцентра для сотрудников сайта.

Как работают Ограничения администратора

Ограничения администратора работают с помощью вызова методов вашей модели, которые представляют действия, предпринимаемые администратором. Метод, вызванный в модели, вернет логическое значение, указывающее, имеет ли администратор разрешение на выполнение этого действия. Поддерживаемые действия методов:

  • canAdd() (администратор может добавлять новые ноды данного типа).
  • canEdit() (администратор может редактировать существующие ноды).
  • canCopy() (администратор может копировать ноды).
  • canManagePermissions() (администратор может редактировать пользовательские разрешения).
  • canDelete() (администратор может удалять ноды).

Класс \IPS\Node\Model определяет эти методы за вас автоматически. Вы создадите ограничения администратора, которые хотите поддерживать в Центре разработчика, а затем сопоставите их с этими методами действий в вашей модели.

Настройка ограничений администратора

Первый шаг это использование Центра разработчика для создания ограничений для вашего приложения. Каждый контроллер в каждом модуле вашего приложения может иметь отдельные ограничения. Ограничения всегда отображаются как простые поля Да/Нет, поэтому формулируются в виде вопроса "Можно _____?". Например, "Можно управлять форумами" или "Можно редактировать настройки?".

Существует несколько поддерживаемых типов разрешений, которые вы можете реализовать:

  • access (то есть администратор может получить доступ ко всей этой ноде).
  • manage (то есть администратор просматривать данную ноду).
  • add
  • edit 
  • copy 
  • permissions 
  • delete 

Обратите внимание, что доступ и управление не имеют связанных методов действий (то есть вы не можете использовать в вашей модели методы canAccess или canManage); вместо этого Диспетчер будет автоматически проверять эти разрешения, если определено, и предотвращать доступ, если владельцем сайта не установлено разрешение Да.

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

addRest.jpg

Это также сформирует языковую строку для перевода описания ограничения, при этом ключ фразы будет в формате r__{key}, где {key} это тот ключ, который вы указали. Это проще всего, если вы придерживаетесь норм именования ограничений и задаете свой ключ в формате {controller} _ {permission}, где {controller} является соответствующим контроллером в вашей модели, а {permission} является одним из типов ограничения в приведенном выше списке, Например, в контроллере форумов для приложения "Форумы", мы имеем следующее:

  • forums_manage
  • forums_add
  • forums_edit
  • ...и так далее.

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

Настройка вашей модели

Для реализации ограничений в вашей модели, вы должны добавить статическое свойство:

protected static $restrictions = array();

Вы должны добавить в этот массив два необходимых ключа:

  • app - ключ вашего приложения.
  • module - модуль, который содержит ограничения, которые вы применяете.

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

prefix - если вы назвали свои ограничения, используя описанный выше способ, вы можете здесь просто указать префикс, и модель автоматически будет использовать правильные разрешения. К примеру, если вы назвали ваши ограничения forums_add и т.д., префикс, который вы укажете для этого значения, будет forum_.

all - если вы хотите использовать одно разрешение для всех действий, просто укажите его, используя это значение.

map - если вы хотите вручную проверять какое действие должно проверять разрешение, добавьте значение с именем map. Это должен быть ассоциативный массив с указанными ниже ключами. Значение для каждого ключа должно быть ключом ограничения, который вы создали в центре разработчика, которое будет проверено для этого действия.

  • add
  • edit
  • copy
  • permissions
  • delete

Перезагрузка методов разрешений

Несмотря на то, что базовая модель определяет и реализует для вас методы действий, могут возникнуть ситуации, когда вам нужно перегрузить их в классе своей модели. Например, если предположить, что у нашего приложения есть параметр, который означает, что добавление новых дочерних узлов не имеет смысла, мы можем сделать:

// app/sources/ExampleModel/ExampleModel.php

function canAdd()
{
	if( $this->some_setting )
	{
		// Нельзя добавить ноды, если включена гипотетическая настройка, поэтому возвращаем здесь FALSE
		return FALSE;
	}
	
	// В других случаях не забудьте вызвать родительский метод
	return parent::canAdd();
}

Использование методов разрешения

В большинстве случаев вам не нужно вручную использовать методы действий, предусмотренные для ограничений администратора. Класс \IPS\Node\Controller автоматически вызовет их при необходимости для создания интерфейса, отображая соответствующие элементы в соответствии с тем, что разрешено администратором. Однако, вы можете вызвать их, если необходимо, например так:

$item = \IPS\forums\Forum::load( 1 );
echo $item->canAdd();

 



×
×
  • Создать...

Важная информация

Используя наш сайт вы соглашаетесь с нашей Политикой конфиденциальности