Руководство ошибок по ролям

Приветствую друзья!

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

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

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

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

Подобно тому, как роли и разрешения позволяют вам делать определенные вещи на компьютерах на работе или в колледже, то же самое применимо и к вашему веб-сайту WordPress.

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

Я собираюсь объяснить различные роли пользователей и уровни возможностей, а также способы их реализации.

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

Каковы роли и возможности пользователей в WordPress?

Роли пользователей — это собирательные термины для ряда возможностей или разрешений, назначаемых пользователям.

Им даны имена, которые дают вам представление о том, какую роль вы можете назначить каждому.

Возможности и разрешения — это одно и то же.

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

WordPress имеет специальную номенклатуру возможностей, которую мы также включаем в пример для каждой роли пользователя.

Например, участник может писать сообщения, но не публиковать их.

Редактор имеет возможность редактировать сообщения от кого угодно и публиковать их.

Подобно тому, как роли работают в реальном мире.

Роли пользователей WordPress называются:

• Супер администратор,
• Администратор,
• Редактор,
• Автор,
• Участник,
• Подписчик.

И не так давно добавили еще две роли, это:

• SEO Editor,
• SEO Manager.

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

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

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

Почему вам нужно контролировать роли и возможности пользователей?

Как только вы открываете свой веб-сайт для других, вы теряете некоторый контроль.

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

Вы можете контролировать это в определенной степени с помощью ролей пользователей.

Роль пользователя помогает обеспечить безопасность вашего веб-сайта, ограничивая то, что может делать кто-то с этой ролью.

Если вы им доверяете, вы можете назначить больше возможностей.

Если вы их еще не знаете, можете назначить скромные возможности.

Пока у пользователя есть возможности выполнять свою работу, остальное полностью зависит от вас.

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

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

Другое использование ролей — сосредоточение внимания пользователей.

Например, если вы предоставляете писателю роль автора, все, что он может сделать, это войти в систему и писать.

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

Они могут делать только то, что позволяет соответствующая роль, что помогает им сосредоточиться.

Роли пользователей WordPress

Давайте подробнее рассмотрим каждую из этих пользовательских ролей WordPress.

Супер администратор

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

Если вы запускаете несколько веб-сайтов с помощью WordPress Multisite, супер администратор похож на администратора, но для всей сети.

Супер администраторы могут:

• Делайте все, что может делать администратор.

Плюс:

• Добавление и удаление веб-сайтов в многосайтовой сети,
• Добавление и удаление других пользователей в сети,
• Изменение или удаление разрешения для других пользователей в сети,
• Добавление, перемещение или удаление страниц и сообщений в сети,
• Модификация или изменение тем и плагинов в сети,
• Переведение веб-сайта в автономный режим или в режим обслуживания по сети.

Роль супер администратора WordPress несет большую ответственность.

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

Согласно WordPress.org, особые возможности супер администратора:

• create_sites
• delete_sites
• manage_network
• manage_sites
• manage_network_users
• manage_network_plugins
• manage_network_themes
• manage_network_options
• upgrade_network
• setup_network

Типичные варианты использования супер администраторов — это управление мульти-сайтом WordPress и всем, что в них происходит.

Администратор

Администратор, или админ, является основным пользователем WordPress.

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

Администраторы могут:

• Добавлять и удалять других пользователей,
• Изменять или удалять разрешения для других пользователей,
• Добавлять, перемещать или удалять страницы и сообщения,
• Модифицировать или изменять темы и плагины,
• Переводить сайт в автономный режим или в режим обслуживания.

Как видите, у администратора большие полномочия.

Если вы даете другому человеку роль администратора на своем веб-сайте, вы должны доверять ему!

Конкретные возможности включают:

• activate_plugins
• delete_others_pages
• delete_others_posts
• delete_pages
• delete_posts
• delete_private_pages
• delete_private_posts
• delete_published_pages
• delete_published_posts
• update_core
• update_plugins
• update_themes
• install_plugins
• install_themes

Посмотреть все возможности администратора вы можете здесь.

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

Редактор

Роль редактора WordPress — это именно то, что вы могли ожидать.

Тот, кто может редактировать страницы и сообщения на сайте.

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

Редакторы могут:

• Добавлять, изменять или удалять сообщения и страницы,
• Создавать контент,
• Создавать категории,
• Модерировать комментарии,
• Добавлять, изменять или удалять изображения или мультимедиа из сообщений и страниц,
• Изменять внутренние и внешние ссылки.

Роль редактора WordPress также является надежной позицией на веб-сайте.

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

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

Конкретные возможности редактора включают:

• edit_others_pages,
• edit_others_posts,
• edit_pages,
• edit_posts,
• edit_private_pages,
• edit_private_posts,
• edit_published_pages,
• edit_published_posts,

Посмотреть все возможности редактора можно здесь.

Типичные варианты использования роли редактора WordPress — редактор или менеджер контента для организации, отвечающей за мониторинг контента и качества.

Автор

Роль автора — это еще одна хорошо названная роль пользователя WordPress.

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

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

Авторы могут:

• Создавать, редактировать или удалять собственные сообщения и страницы,
• Добавлять, изменять или удалять изображения или медиа-файлы из собственных сообщений и страниц,
• Изменять внутренние и внешние ссылки в собственных сообщениях и на страницах.

У авторов есть разрешение только изменять свои собственные работы.

Обычно они видят только свою работу на панели инструментов WordPress.

Типичные возможности автора включают:

• delete_posts
• delete_published_posts
• edit_posts
• edit_published_posts
• publish_posts
• read
• upload_files

Посмотреть все возможности автора можно здесь.

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

Участник

Роль участника WordPress аналогична роли автора, но участники не могут публиковать сообщения на сайте.

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

Участники могут:

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

Типичные возможности участника включают:

• delete_posts,
• edit_posts,
• read,
• read Reusable Blocks.

Посмотреть все возможности участника можно здесь.

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

Подписчик

Роль подписчика WordPress — это именно то, что написано в админке по умолчанию.

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

Подписчики могут:

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

Эта роль пользователя в основном используется для веб-сайтов с подпиской, LMS (систем управления обучением) или других типов веб-сайтов с личными зонами.

Подписчик имеет только возможность чтения.

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

Как назначать роли пользователям?

Назначить роли пользователям очень просто.

Вы можете сделать это при регистрации пользователя или изменить его роль в любое время.

Сначала мы рассмотрим назначение роли новому пользователю, а затем изменение роли существующего пользователя.

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

Чтобы назначить роль новому пользователю:

1. Выберите «Пользователи» и «Добавить нового» в левом меню на панели инструментов WordPress,
2. Введите имя пользователя и данные пользователя,
3. Выберите меню по роли внизу страницы нового пользователя,
4. Назначьте соответствующую роль,
5. Нажмите синюю кнопку «Добавить нового пользователя», чтобы создать пользователя.

Теперь этот пользователь появится на панели управления пользователя с соответствующей ролью в таблице.

Чтобы изменить роль для существующего пользователя:

1. Выберите «Пользователи» и «Все пользователи» в левом меню на панели инструментов WordPress,
2. Установите флажок рядом с пользователем, которого хотите изменить,
3. Выберите раскрывающееся меню «Изменить роль на» вверху таблицы,
4. Выберите соответствующую роль из меню,
5. Нажмите кнопку «Изменить» рядом с этим меню.

Роль пользователя теперь изменится на то, что вы выбрали.

Как назначать возможности и настраивать роли?

Теперь у вас есть представление о том, какие существуют роли пользователей, давайте перейдем к возможностям.

Вы можете изменить возможности, используя базу данных WordPress или изменив файл «WP_Roles», но, как всегда, для этого есть плагин.

Я использую «WPFront User Role Editor».

Это бесплатно, просто и он выполняет свою работу.

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

После установки вы можете найти инструмент в новом пункте меню «Roles», который вы увидите на панели инструментов WordPress.

Чтобы назначить разрешение роли, сделайте следующее:

• Выберите «All Roles» в разделе «Roles» в боковом меню WordPress,
• Выберите роль, для которой вы хотите назначить разрешение, чтобы открыть окно редактирования роли,
• Выберите разрешение, которое вы хотите назначить, в окне «Capabilities», установив флажок рядом с ним,
• Выберите «Update Role» внизу страницы.

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

Как создать новые пользовательские роли?

Добавление новой роли пользователя в WordPress также очень просто при использовании плагина.

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

Чтобы создать собственную роль в WordPress:

1. Выберите «Roles» и «Add New» на панели инструментов WordPress,
2. Назовите свою новую роль там, где написано «Display Name» и «Role Name»,
3. Установите флажки рядом с каждой возможностью, которую вы хотите добавить к роли,
4. Нажмите синюю кнопку «Add New Role» внизу страницы, чтобы добавить новую роль.

Если ваша новая роль похожа на существующую, вы можете использовать действие «Copy From» в левом верхнем углу экрана «Add New Role».

Выберите роль в раскрывающемся меню и выберите рядом с ней «Apply».

Это импортирует возможности из этой роли.

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

Это очень простой процесс!

Как удалить роли пользователей из WordPress?

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

После этого выполните следующие действия, чтобы удалить роль с вашего веб-сайта.

Удалите роль пользователя в WordPress:

1. Выберите «Roles» и «All Roles» на панели инструментов WordPress,
2. Выберите роль из таблицы на экране «Roles»,
3. Наведите указатель мыши на него, пока не увидите «Delete»,
4. Выберите «Delete» и подтвердите свой выбор.

Теперь вы должны увидеть обновленную таблицу ролей без той роли, которую вы только что удалили. Это так просто!

Пять лучших плагинов для ролей пользователей WordPress

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

Для остальных из нас плагины быстро справляются с управлением ролями и категориями.

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

WPFront User Role Editor

WPFront User Role Editor — это простой и серьезный плагин для роли пользователя, который упрощает управление возможностями и ролями в WordPress.

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

Плагин также может контролировать возможности таких плагинов, как Elementor, WP Portfolio, Schema Pro и других плагинов, но для этого вам понадобится премиум-версия.

WPFront User Role Editor предоставляется бесплатно или 29,99 долларов США для одного сайта.

User Role Editor

User Role Editor — еще один компетентный плагин для управления ролями и возможностями.

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

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

Жаль, что все хорошие инструменты закрыты за премиум-версией.

User Role Editor имеет бесплатную версию и премиум-версию, которая стоит от 29 долларов в год для одного сайта.

Members WordPress Plugin

Members WordPress Plugin от MemberPress.

Это еще один очень эффективный плагин, который помогает вам контролировать роли и возможности пользователей.

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

Плагин включает в себя множество вариантов разрешений, инструменты клонирования ролей, интеграцию с ведущими плагинами электронной коммерции, такими как «Easy Digital Downloads» и «WooCommerce», а также некоторые полезные инструменты, если вы запускаете веб-сайты членства.

Members WordPress Plugin можно использовать бесплатно.

Advanced Access Manager

Advanced Access Manager (AAM) — еще один очень удобный плагин для управления пользователями и возможностями в WordPress.

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

Существует бесплатная и премиум-версия плагина со многими основными функциями, которые вам понадобятся в бесплатной версии.

Уже одно это заставляет задуматься о AAM.

Premium добавляет дополнительные функции безопасности для улучшения основного плагина.

Advanced Access Manager имеет бесплатную версию и премиум по цене от 39 долларов.

PublishPress Capabilities

PublishPress Capabilities — это моя последняя рекомендация по управлению ролями и разрешениями пользователей в WordPress.

Это полнофункциональный плагин с простой системой флажков для добавления возможностей.

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

PublishPress Capabilities имеет бесплатную версию и премиум-версию, которая стоит от 69 долларов в год.

Последние мысли

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

Когда ваш веб-сайт находится на стадии, когда вам нужна небольшая помощь, не нужно беспокоиться о том, что люди что-то напутают.

Назначьте правильную роль пользователя или настройте существующую, и вы можете расслабиться, зная, что ваш веб-сайт в безопасности.

Надеюсь, эта статья предоставила информацию, необходимую для понимания и полного использования ролей и возможностей пользователей на вашем собственном веб-сайте!

Поделитесь своими ответами ниже, в секции комментариев!

Ну, а у меня на этом все, буду заканчивать — до скорых встреч и берегите себя и своих близких.

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

Что такое партнерские роли?

Партнерские роли — это конкретные обязанности, ответственность и ожидания, возлагаемые на каждого партнера в бизнесе. Партнеры подробно излагают эту информацию в официальном партнерском соглашении, которое они разрабатывают совместно. Без этого соглашения организация вашего бизнеса по умолчанию подчиняется законодательству вашего штата о бизнесе.

Что следует включить в соглашение о партнерстве

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

• Какой вклад вносит каждый партнер в компанию

• Какую долю собственности получает каждый партнер

• Будете ли вы принимать решения большинством голосов, единогласно или вы можете принимать некоторые решения в одностороннем порядке

• Как вы будете делить прибыль, включая то, сколько получает каждый партнер и когда вы будете ее распределять

• Могут ли партнеры связывать организацию договором или обязательствами и какие-либо ограничения на эти полномочия

• Процедуры, позволяющие новым партнерам присоединяться к компании

• Как действовать в случае смерти партнера или его отказа от партнерства

• Как разрешать споры, например, положение о посредничестве

• Как долго продлится партнерство, даже если оно будет бессрочным

• Стандарты поведения, включая положение о конфликте интересов

Преимущества распределения партнерских ролей

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

Как распределить роли в рамках партнерства

Вот шаги по определению партнерских ролей:

1. Определите ответственность каждого партнера

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

• Полное партнерство: Полное партнерство — это партнерство, в котором все партнеры участвуют в ежедневных операциях бизнеса и несут равную ответственность.

• Ограниченное партнерство: В партнерствах с ограниченной ответственностью есть один или несколько партнеров, которые участвуют в ежедневных операциях, а также один или несколько партнеров, которые не участвуют в повседневных функциях компании.

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

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

2. Напишите список ваших потребностей в управлении бизнесом

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

• Человеческие ресурсы

• Общее руководство

• Распределение

• Маркетинг

• Продажи

• Производство

• Финансы

• Соблюдение правовых норм

3. Создайте должностные инструкции по каждой управленческой потребности

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

• Основные обязанности и ответственность

• Требования к образованию и опыту работы

• Необходимые навыки и черты характера

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

4. Назначение задач

После того как вы изложите описание каждой должности, вы можете изучить сильные стороны и компетенции каждого партнера. В рамках этого процесса вы можете рассмотреть личностные характеристики, предыдущий опыт и интересы. Если никто из партнеров не обладает необходимым опытом или знаниями, чтобы лично контролировать эту роль, вы можете поручить партнеру нанять человека или команду для управления этой работой. Партнер будет контролировать работу отдела, чтобы убедиться, что команда выполняет цели, указанные в каждом описании.

5. Формализуйте роли в письменном виде

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

6. Проводить регулярные встречи

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

Роли (Roles) и Права (Permissions) в Laravel являются наиболее важной частью любого Laravel приложения, где необходимо ограничивать варианты его использование. Если вы погуглите Laravel Roles and Permissions, то найдете несколько пакетов для добавления подобного функционала. Вы можете установить их в свое приложение через Composer и, после небольшой настройки, их можно уже использовать.

В большинстве случаев эти пакеты поставляются с дополнительным функционалом, который вам вообще не нужен. Что если, вам просто хотите систему управления ролями и правами под ваши конкретные нужды. Когда речь заходит о функционале уже доступным через Composer, многие называют это «изобретение велосипеда».

По моему мнению, если мне нужно написать какой-то простой код, то зачем мне раздувать список зависимостей проекта? Кроме того, самостоятельно внедряя все это, вы в будущем получите полный контроль над кодом при необходимости новых изменений.

В этой статье я расскажу вам, как вы можете самостоятельно пошагово реализовать Роли и Права в Laravel.

Настройка приложения

Начнем урок с создания нового приложения Laravel с помощью приведенной ниже команды composer.

composer create-project laravel/laravel RolesAndPermissions

После создания приложения, перейдите в папку RolesAndPermissions и настройте учетные данные базы данных в файле .env.

Создание каркаса аутентификации

В Laravel 6 команда make:auth и весь фронтенд были перемещены в автономный пакет laravel/ui. Мы установим его, выполнив следующую команду.

composer require laravel/ui

Теперь мы сгенерируем дефолтный каркас аутентификации из предыдущих версиях Laravel.

php artisan ui vue --auth

После чего, выполните следующую команду, чтобы скомпилировать и сгенерировать необходимые ресурсы для фронтенд шаблонов.

npm install && npm run dev

Запустить встроенный сервер можно с помощью команды php artisan serve. Он будет работать по адресу localhost:8000.

Генерация Моделей и Миграций

В этом разделе мы создадим две новые модели под названием Role и Permission вместе с их миграциями. Для этого мы запустим две нижеприведенные команды в терминале командной строки.

php artisan make:model Role -m

php artisan make:model Permission -m

Флаг -m позволит генерировать миграцию вместе с моделью. Откроем файлы миграции и обновим их в соответствии со структурой таблицы базы данных, которую мы хотим реализовать.

Откройте файл миграции Роли в папке database/migrations и вставьте в него.

use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;

class CreateRolesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('roles', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('slug');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('roles');
    }
}

Мы просто добавили поля name и slug. Теперь откройте файл миграции Прав и вставьте в него.

use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;

class CreatePermissionsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('permissions', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('slug');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('permissions');
    }
}

Так же, как и в предыдущей миграции, мы добавили два поля name и slug. Всё просто.

Добавление необходимых сводных таблиц

Перед миграцией созданных таблиц, давайте определим некоторые отношения, которые мы хотели бы реализовать для Ролей и Прав.

1. Пользователь может иметь Права
2. Пользователь может иметь Роли
3. Роль может иметь Права

Для этих трех отношений нам нужно добавить три сводные таблицы, чтобы создать отношение «Многие ко Многим» между моделями User, Role и Permission.

Давайте создадим миграции для этих сводных таблиц. Сначала мы создадим таблицу для связи между Пользователем и Правами.

php artisan make:migration create_users_permissions_table

Откройте только что созданный файл create_users_permissions_table и скопируйте в него.

use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;

class CreateUsersPermissionsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users_permissions', function (Blueprint $table) {
            $table->unsignedBigInteger('user_id');
            $table->unsignedBigInteger('permission_id');

            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
            $table->foreign('permission_id')->references('id')->on('permissions')->onDelete('cascade');

            $table->primary(['user_id','permission_id']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('users_permissions');
    }
}

В этой миграции мы определили два столбца user_id и permission_id с внешними ключами в соответствующих таблицах. Плюс, мы определили первичные ключи для этих двух полей.

Далее мы создадим ссылку между таблицами Пользователей и Ролей.

php artisan make:migration create_users_roles_table

Откройте созданный файл миграции create_users_roles_table и скопируйте в него.

use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;

class CreateUsersRolesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users_roles', function (Blueprint $table) {
            $table->unsignedBigInteger('user_id');
            $table->unsignedBigInteger('role_id');

            $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
            $table->foreign('role_id')->references('id')->on('roles')->onDelete('cascade');

            $table->primary(['user_id','role_id']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('users_roles');
    }
}

Аналогично предыдущей миграции, у нас также есть два поля user_id и role_id с внешними ключами в соответствующих таблицах и первичными ключами.

Теперь мы создадим сводную таблицу между Ролями и Правами.

php artisan make:migration create_roles_permissions_table

Откройте файл миграции create_roles_permissions_table и скопируйте в него.

use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesSchema;

class CreateRolesPermissionsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('roles_permissions', function (Blueprint $table) {
            $table->unsignedBigInteger('role_id');
            $table->unsignedBigInteger('permission_id');

            $table->foreign('role_id')->references('id')->on('roles')->onDelete('cascade');
            $table->foreign('permission_id')->references('id')->on('permissions')->onDelete('cascade');

            $table->primary(['role_id','permission_id']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('roles_permissions');
    }
}

В этой миграции мы определили два поля role_id и permission_id с внешним и первичным ключами.

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

php artisan migrate

Если все прошло успешно, то вы увидите в вашей базе данных таблицы roles, permissions и три сводные таблицы.

Отношения Ролей и Прав

В этом разделе мы настроим отношения Ролей и Прав. Для Пользователей мы добавим отношения в следующем разделе. Откройте файл модели Role.php и добавьте отношение belongsToMany.

class Role extends Model
{
    public function permissions()
    {
        return $this->belongsToMany(Permission::class,'roles_permissions');
    }
}

Откройте файл модели Permission.php и скопируйте в него.

class Permission extends Model
{
    public function roles()
    {
        return $this->belongsToMany(Role::class,'roles_permissions');
    }
}

Так мы определили отношения «Многие ко Многим» между Ролями и Правами.

Трейт HasRolesAndPermissions для модели User

Теперь займемся моделью User. Пользователь может иметь много Прав и много Ролей. То же самое наоборот, Роль может иметь много Пользователей, а Право может иметь много Пользователей. Поэтому нам нужно создать отношение «Многие ко Многим» в модели User.

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

В папке app создайте новую папку и назовите ее «Traits». Создайте в ней файл и назовите его HasRolesAndPermissions.php.

Скопируйте в него следующий код.

namespace AppTraits;

use AppModelsRole;
use AppModelsPermission;

trait HasRolesAndPermissions
{
    /**
     * @return mixed
     */
    public function roles()
    {
        return $this->belongsToMany(Role::class,'users_roles');
    }

    /**
     * @return mixed
     */
    public function permissions()
    {
        return $this->belongsToMany(Permission::class,'users_permissions');
    }
}

Мы задали отношения roles и permissions в соответствующих моделях. Теперь для того, чтобы использовать этот трейт в вашей модели User, откройте файл User.php и добавьте в него использование трейта HasRolesAndPermissions:

use AppTraitsHasRolesAndPermissions;
use IlluminateContractsAuthMustVerifyEmail;
use IlluminateFoundationAuthUser as Authenticatable;
use IlluminateNotificationsNotifiable;

class User extends Authenticatable
{
    use Notifiable, HasRolesAndPermissions; // Наш новый трейт

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = [
        'name', 'email', 'password',
    ];

    /**
     * The attributes that should be hidden for arrays.
     *
     * @var array
     */
    protected $hidden = [
        'password', 'remember_token',
    ];

    /**
     * The attributes that should be cast to native types.
     *
     * @var array
     */
    protected $casts = [
        'email_verified_at' => 'datetime',
    ];
}

Пользователь hasRole

Чтобы проверить, есть ли у текущего залогиненного Пользователя Роль, мы добавим новую функцию в трейт HasRolesAndPermissions. Откройте этот файл трейта и добавьте в него эту функцию.

/**
 * @param mixed ...$roles
 * @return bool
 */
public function hasRole(... $roles ) {
    foreach ($roles as $role) {
        if ($this->roles->contains('slug', $role)) {
            return true;
        }
    }
    return false;
}

В функцию мы передаем массив $roles и проверяем в цикле, содержат ли роли текущего пользователя заданную роль.

Пользователь hasPermission

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

/**
 * @param $permission
 * @return bool
 */
public function hasPermission($permission)
{
    return (bool) $this->permissions->where('slug', $permission)->count();
}

/**
 * @param $permission
 * @return bool
 */
public function hasPermissionTo($permission)
{
    return $this->hasPermission($permission);
}

Метод проверяет, содержат ли права пользователя заданное право, если да, то тогда он вернет true, а иначе false.

Пользователь hasPermissionThroughRole

Как мы знаем, у нас между Ролями и Правами есть отношение «Многие ко Многим». Это позволяет нам проверять, есть ли у Пользователя Права через его Роль. Чтобы это реализовать, мы добавим новую функцию в наш трейт HasRolesAndPermissions.

/**
 * @param $permission
 * @return bool
 */
public function hasPermissionThroughRole($permission)
{
    foreach ($permission->roles as $role){
        if($this->roles->contains($role)) {
            return true;
        }
    }
    return false;
}

Эта функция проверяет, привязана ли Роль с Правами к Пользователю. Метод hasPermissionTo() проверит эти два условия.

Обновите метод hasPermissionTo, как показано ниже.

/**
 * @param $permission
 * @return bool
 */
public function hasPermissionTo($permission)
{
   return $this->hasPermissionThroughRole($permission) || $this->hasPermission($permission->slug);
}

Теперь у нас есть метод, который будет проверять, есть ли у Пользователя Права напрямую или через Роль. Позже мы будем использовать этот метод для добавления кастомной blade-директивы.

Выдача Прав

Предположим, что мы хотим прикрепить некоторые Права к текущему Пользователю. Для этого мы добавим новый метод в трейт HasRolesAndPermissions.

/**
 * @param array $permissions
 * @return mixed
 */
public function getAllPermissions(array $permissions)
{
    return Permission::whereIn('slug',$permissions)->get();
}

/**
 * @param mixed ...$permissions
 * @return $this
 */
public function givePermissionsTo(... $permissions)
{
    $permissions = $this->getAllPermissions($permissions);
    if($permissions === null) {
        return $this;
    }
    $this->permissions()->saveMany($permissions);
    return $this;
}

Первый метод получает все Права на основе переданного массива. Во второй функции мы передаем Права в виде массива и получаем все Права из базы данных на основе массива.

Далее мы используем метод permissions() для вызова метода saveMany(), чтобы сохранить разрешения для текущего пользователя.

Удаление Прав

Чтобы удалить Права Пользователя, мы передаем Права методу deletePermissions() и удаляем все прикрепленные Права с помощью метода detach().

/**
 * @param mixed ...$permissions
 * @return $this
 */
public function deletePermissions(... $permissions )
{
    $permissions = $this->getAllPermissions($permissions);
    $this->permissions()->detach($permissions);
    return $this;
}

/**
 * @param mixed ...$permissions
 * @return HasRolesAndPermissions
 */
public function refreshPermissions(... $permissions )
{
    $this->permissions()->detach();
    return $this->givePermissionsTo($permissions);
}

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

Добавление сидеров

До сих пор мы реализовали основные Роли и Права в нашем приложении Laravel, ничего не тестирую. Для быстрого тестирования мы сделаем несколько классов Seed, которые добавят в ваши таблицы несколько фиктивных данных.

php artisan make:seeder PermissionSeeder

php artisan make:seeder RoleSeeder

php artisan make:seeder UserSeeder

Откройте класс RoleSeeder и скопируйте в него.

namespace DatabaseSeeders;

use AppModelsRole;
use IlluminateDatabaseSeeder;

class RoleSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $manager = new Role();
        $manager->name = 'Project Manager';
        $manager->slug = 'project-manager';
        $manager->save();

        $developer = new Role();
        $developer->name = 'Web Developer';
        $developer->slug = 'web-developer';
        $developer->save();
    }
}

Откройте класс PermissionSeeder и скопируйте в него.

namespace DatabaseSeeders;

use AppModelsPermission;
use IlluminateDatabaseSeeder;

class PermissionSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $manageUser = new Permission();
        $manageUser->name = 'Manage users';
        $manageUser->slug = 'manage-users';
        $manageUser->save();

        $createTasks = new Permission();
        $createTasks->name = 'Create Tasks';
        $createTasks->slug = 'create-tasks';
        $createTasks->save();
    }
}

Далее, в классе UserSeeder мы создадим несколько Пользователей и добавим к ним Роли и Права.

namespace DatabaseSeeders;

use AppModelsRole;
use AppModelsUser;
use AppModelsPermission;
use IlluminateDatabaseSeeder;

class UserSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        $developer = Role::where('slug','web-developer')->first();
        $manager = Role::where('slug', 'project-manager')->first();
        $createTasks = Permission::where('slug','create-tasks')->first();
        $manageUsers = Permission::where('slug','manage-users')->first();

        $user1 = new User();
        $user1->name = 'Jhon Deo';
        $user1->email = 'jhon@deo.com';
        $user1->password = bcrypt('secret');
        $user1->save();
        $user1->roles()->attach($developer);
        $user1->permissions()->attach($createTasks);


        $user2 = new User();
        $user2->name = 'Mike Thomas';
        $user2->email = 'mike@thomas.com';
        $user2->password = bcrypt('secret');
        $user2->save();
        $user2->roles()->attach($manager);
        $user2->permissions()->attach($manageUsers);
    }
}

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

namespace DatabaseSeeders;

use IlluminateDatabaseSeeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     *
     * @return void
     */
    public function run()
    {
        $this->call(RoleSeeder::class);
        $this->call(PermissionSeeder::class);
        $this->call(UserSeeder::class);
    }
}

Чтобы сохранить данные в базе данных, выполните в терминале следующую команду.

php artisan db:seed

Проверьте Права и Роли Пользователя, как показано ниже.

$user = AppModelsUser::find(1);
dd($user->hasRole('web-developer')); //вернёт true
dd($user->hasRole('project-manager')); //вернёт false
dd($user->givePermissionsTo('manage-users')); //выдаём разрешение
dd($user->hasPermission('manage-users')); //вернёт true

Добавление кастомной blade-директивы для Ролей и Прав

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

php artisan make:provider RolesServiceProvider

Не забудьте добавить RolesServiceProvider в список providers в файле config/app.php. Откроем свежесозданный RolesServiceProvider и обновим его с помощью приведенного ниже кода.

namespace AppProviders;

use IlluminateSupportFacadesBlade;
use IlluminateSupportServiceProvider;

class RolesServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        Blade::directive('role', function ($role){
            return "<?php if(auth()->check() && auth()->user()->hasRole({$role})): ?>";
        });

        Blade::directive('endrole', function ($role){
            return "<?php endif; ?>";
        });
    }
}

В сервис провайдере мы объявляем кастомную директиву, используя фасад Blade. В первой директиве мы проверяем, прошел ли Пользователь аутентификацию и имеет ли он заданную роль. Во второй директиве — закрываем оператор if.

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

@role('project-manager')
 Project Manager Panel
@endrole 

@role('web-developer')
 Web Developer Panel
@endrole

Очень просто.

До сих пор мы использовали Роли в нашей директиве. Для Прав мы будем использовать директиву can, чтобы проверить, есть ли у Пользователя Право. Вместо использования $user->hasPermissionTo() мы будем использовать Gate::allows('manage-users').

Для достижения этой функциональности мы создадим нового сервис провайдера и назовем его PermissionServiceProvider.

php artisan make:provider PermissionServiceProvider

Не забудьте добавить PermissionServiceProvider в список providers в файле config/app.php. Откройте его и обновите его с помощью приведенного ниже кода.

namespace AppProviders;

use AppModelsPermission;
use IlluminateSupportFacadesGate;
use IlluminateSupportServiceProvider;

class PermissionServiceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        try {
            Permission::get()->map(function ($permission) {
                Gate::define($permission->slug, function ($user) use ($permission) {
                    return $user->hasPermissionTo($permission);
                });
            });
        } catch (Exception $e) {
            report($e);
            return false;
        }
    }
}

Здесь мы сопоставляем все Права, определяем slug Права (в нашем случае) и проверяем, есть ли у Пользователя Право. Теперь вы можете проверить Права Пользователя, как показано ниже.

//вернёт true для текущего пользователя, если ему дано право управлять пользователями
Gate::allows('manage-users');

Добавление Мидлвара для Ролей и Прав

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

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

php artisan make:middleware RoleMiddleware

Откройте созданный класс RoleMiddleware и скопируйте в него.

namespace AppHttpMiddleware;

use Closure;

class RoleMiddleware
{
    /**
     * Handle an incoming request.
     * @param $request
     * @param Closure $next
     * @param $role
     * @param null $permission
     * @return mixed
     */
    public function handle($request, Closure $next, $role, $permission = null)
    {
        if(!auth()->user()->hasRole($role)) {
            abort(404);
        }
        if($permission !== null && !auth()->user()->can($permission)) {
            abort(404);
        }
        return $next($request);
    }
}

В этом мидлваре мы проверяем, имеет ли текущий Пользователь заданную Роль/Право, и, если нет, то возвращаем страницу с ошибкой 404. Существует много возможностей использовать Роли и Права в мидлваре для управления входящими запросами, все зависит от требований вашего приложения.

Перед использованием этого мидлвара вы должны добавить его в файл AppHttpKernel.php.

Обновите массив $routeMiddleware как показано ниже.

 /**
 * The application's route middleware.
 *
 * These middleware may be assigned to groups or used individually.
 *
 * @var array
 */
protected $routeMiddleware = [
    'auth' => AppHttpMiddlewareAuthenticate::class,
    'auth.basic' => IlluminateAuthMiddlewareAuthenticateWithBasicAuth::class,
    'bindings' => IlluminateRoutingMiddlewareSubstituteBindings::class,
    'cache.headers' => IlluminateHttpMiddlewareSetCacheHeaders::class,
    'can' => IlluminateAuthMiddlewareAuthorize::class,
    'guest' => AppHttpMiddlewareRedirectIfAuthenticated::class,
    'password.confirm' => IlluminateAuthMiddlewareRequirePassword::class,
    'signed' => IlluminateRoutingMiddlewareValidateSignature::class,
    'throttle' => IlluminateRoutingMiddlewareThrottleRequests::class,
    'verified' => IlluminateAuthMiddlewareEnsureEmailIsVerified::class,
    'role'  =>  AppHttpMiddlewareRoleMiddleware::class, // наш мидлвар роли
];

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

Route::group(['middleware' => 'role:web-developer'], function() {
   Route::get('/dashboard', function() {
      return 'Добро пожаловать, Веб-разработчик';
   });
});

Выводы

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

Вы можете найти код этой статьи в репозитории Laravel Roles Permissions.

Update 22.05.2020: Исправлены ошибка с типами полей в миграциях.

Update 10.09.2020: Добавлены неймспейсы, исправлены сидеры, добавлены пояснения к созданию провайдеров.

Update 23.09.2020: Совместимость с Laravel 8: изменено расположение моделей. Исправлена ошибка Trying to get property 'slug' of non-object. Исправлено использование проверки прав.

Автор: Larashout
Перевод: Алексей Широков

Задать вопросы по урокам можно на нашем форуме.

2 часа назад, Trabelsi сказал:

Господа эксперты, что можно улучшить тут?

Я не эксперт, но твоя тыцка «shoot on sight» только ухудшает недоработку. Грубо говоря, лечишь симптом, а не болезнь.
Сколько дальних ударов кстати?

Вопрос — что по ЦП, есть ли у него инструкции? Судя по таткике, должны быть проблемы с креативом.
По таргетмену не понял тоже. Его берут же под конкретные нужды. Если брать нападающего, потому что не знаешь, кого брать — то лучше кого-то другого.

Я бы сказал, что из трио полузащитников один по любому должен быть плеймейкер. В зависимости от позиции и роли можно раскидать остальные. Например DLP(s)-BBM-CAM(a) или RPM-CM(d)-CAM(a) или BBM-CM(d)-AP(s/a) и т.д. Вариантов там много. 

SS — это узкопрофильная роль. Я с ней практически не сталкивался, но у него и сверху и снизу нет подходящих ролей. Условные BBM-SS-F9 наверное смотрелись бы куда веселее.

Линию обороны я бы вернул на баланс, максимум на одну ступеньку выше, но не вижу смысла, тем более за не самый сильный клуб. А одного из фуллбэков перевёл бы в атаку (того, который с оборонительным ЦП)
Вечный вопрос про одновременное использование «опека» и «больше прессинга» — кажется, что велик риск играть в собачки, бегая за мячом. Либо/либо. Я бы выбрал прессинг, если идея играть в контрфутбол и опеку+жестче в отборе, если игроки не вывозят. А лучше попробовать и то и другое и выбрать на практике.

Ну и с КП тоже похоже на полумеру. Тут либо два W + TM , либо два IF которые будут нагружать центр. IF + TM как то чудновато, хотя может нет-нет да скинет ему чего-нибудь  А так FB(s)+IF(a) и FB(a)+IF(s) очень хорошие крылья, главное чтобы центр соответствовал.

В общем, выглядит как будто две тактики смешали в одну  

UPD — А, ну и по ментальности. Судя по всему, ты хочешь играть побыстрее? Тогда попробуй Positive, не меняя темп и пас. Я так с Ромой как раз стал чемпионом с 4231 на наступательной. У тебя на балансе очень может быть, что будет не хватать риска, а если клуб не самый сильный, то через владение могут быть проблемы — слишком медленный переход и потеря мяча при уязвимых позициях

Изменено 15 февраля, 2020 пользователем Scipione

Ошибка при выполнении обновления вспомогательных данных! ☑ 0

buketovav

03.01.22

✎

12:52

1

buketovav

03.01.22

✎

13:11

2

ДенисЧ

03.01.22

✎

13:54

Ну так убери эти права…

3

buketovav

03.01.22

✎

13:55

этих прав нет в расширении, а из основной конфигурации их убирать нельзя

4

buketovav

03.01.22

✎

14:25

5

PLUT

03.01.22

✎

15:20

6

buketovav

03.01.22

✎

15:31

(5) если бы было так все просто, т я бы не стал сюда писать, я уже попробовал много вариантов

7

buketovav

03.01.22

✎

15:52

8

hhhh

03.01.22

✎

17:06

9

ДедМорроз

03.01.22

✎

17:30

Можно константу версии стереть и запустить.

10

buketovav

04.01.22

✎

10:23

(8) ну нет же, я же написал, что при выполнении всех процедур я ловлю снова такую же ошибку, не помогает /С ЗапуститьОбновлениеИнформационнойБазы

11

hhhh

04.01.22

✎

10:59

(10) обновление запускается? Чисто визуально следишь за тем как обновление происходит? До конца доходит?

12

buketovav

04.01.22

✎

11:00

(11) запускается и через время получаю ту же самую ошибку

13

buketovav

04.01.22

✎

11:06

14

buketovav

04.01.22

✎

11:07

и так всегда, чтобы я не делал все время одна и та же ошибка

15

buketovav

04.01.22

✎

11:08

16

Ёпрст

04.01.22

✎

11:24

(15) и это делал ?

правильно набирать:

/c ЗапуститьОбновлениеИнформационнойБазы

Т.е. /c должно быть на латинице

17

buketovav

04.01.22

✎

11:27

(16) конечно делал

18

Ёпрст

04.01.22

✎

11:28

(17) ну, тогда выкидывай к едрени фени все расширения, обновляй базу, потом обратно их накатывай

19

buketovav

04.01.22

✎

11:29

(18) понял, пошел пробовать

20

buketovav

04.01.22

✎

11:30

(16) без расширения это работает, а с расширением нет…

21

buketovav

04.01.22

✎

11:33

может ли на это влиять назначение расширения? я сделал расширение «Дополнение»

22

Фрэнки

04.01.22

✎

11:34

(20) У тебя это самое Расширение откуда к тебе прилетело?

23

Фрэнки

04.01.22

✎

11:35

И на какую конфу его вешаешь, с какого релиза на какой прыгает обновление типовой?

24

buketovav

04.01.22

✎

11:37

Лабораторная информационная система (2.0.2.66)

Я делаю не обновление системы

Я добавил расширение, в которое добавил самописный документ, справочники, РН и РС, после запуска 1С в режиме предприятие стал ловить такую ошибку

25

buketovav

04.01.22

✎

11:39

И в режиме предприятия при попытке создать тот самый новый документ из расширения я получаю ошибку — Для объекта метаданных «Документ.Извещение»

не найден идентификатор в справочнике «Идентификаторы объектов метаданных» и

регистре сведений «Идентификаторы объектов версий расширений».

26

hhhh

04.01.22

✎

11:42

(25) ну вручную добавь в этот справочник и регистр, чего она там не находит. Это же 2 строчки.

27

buketovav

04.01.22

✎

11:43

(26) как бы ничего не сломать

28

Фрэнки

04.01.22

✎

11:47

29

buketovav

04.01.22

✎

11:48

(28) понял, спасибо

30

buketovav

04.01.22

✎

12:12

что вообще значит «неразделенного объекта»?

Роль «Полные права» содержит право Изменение неразделенного объекта Справочник.

31

buketovav

04.01.22

✎

12:12

может в этом какая-то проблема?

32

ДенисЧ

04.01.22

✎

12:23

33

buketovav

04.01.22

✎

12:32

(32)Спасибо, но у меня нет доступа к ИТС

34

ДенисЧ

04.01.22

✎

15:31

(33) Там есть демо-доступ на 7 дней

35

arsik

04.01.22

✎

15:35

(33) Может тебе префикс расширения поменять на первый символ не подчеркивание?

36

buketovav

05.01.22

✎

10:09

(35) не думаю, что это может влиять

или у Вас был подобный опыт?

37

hhhh

05.01.22

✎

14:49

(36) ну, покажи строку 2702. Что там в ней конкретно?

38

buketovav

06.01.22

✎

10:14

39

buketovav

07.01.22

✎

12:13

40

arsik

07.01.22

✎

19:53

(39) У меня как то подобное было, непонятное, при обновлении. Оказалось, что 1с при выпуске стандартных сейчас не проверяет работу в толстом клиенте и просто часть не выполняется, т.к. часть кода была обрамлена в директивы неверные.

41

buketovav

07.01.22

✎

21:04

(40) то есть попробовать выполнить в тонком клиенте? как Вы это решали?

42

timurhv

07.01.22

✎

21:34

>короч как удалось выяснить. то данная версия БСП не хочет сама обновлять идентификаторы в справочнике идентификаторов метаданных

Есть обработка обновления вспомогательных данных в составе БСП.

Для проверки всех своих писанин есть обработка ПроверкаВнедренияБСП.

43

arsik

07.01.22

✎

21:41

(41) Ну запусти в тонком клиенте.

44

buketovav

08.01.22

✎

11:20

(43) не помогает

45

buketovav

08.01.22

✎

11:20

(42) попробую

46

buketovav

08.01.22

✎

12:14

(42) найти не могу этот отчет

47

ДенисЧ

08.01.22

✎

12:17

(46) В дистрибутиве БСП он есть.

48

buketovav

08.01.22

✎

12:29

(47) у меня нет дистрибутива БСП(((

49

ДенисЧ

08.01.22

✎

12:54

(48) Скачай с итс… Ну, или с известных сайтов…

50

buketovav

08.01.22

✎

13:16

(49) нашел, сказал, запустил отчет и он мне сказал — «Выполнение одного или нескольких заданий завершилось с ошибкой»

51

timurhv

08.01.22

✎

13:56

(50) вам сперва ошибки с помощью «ПроверкаВнедренияБСП» исправить, а в обновлении вспомогательных данных есть гибкая настройка, где можно выбрать нужные элементы.

Если сервер 32 разрядный, то бывает памяти не хватает и падает с ошибкой.

52

buketovav

08.01.22

✎

14:04

53

buketovav

08.01.22

✎

14:12

Содержание:

1.    Почему возникает ошибка при расширении конфигурации

2.    Решение проблемы с ошибкой при расширении конфигурации   

1.    Почему возникает ошибка при расширении конфигурации

Описан готовый механизм решения следующей проблемы:

А теперь разберем пример на «простом языке».

Была задача создать новые роли в расширении. Режим совместимости конфигурации ниже 8.3.13 (т.е. нет возможности применения «Основные роли» в том числе). При назначении ролей полноправным пользователям выявлена проблема: роли из расширения конфигурации 1С 8.3 недоступны (по вышеуказанной причине).

2.    Решение проблемы с ошибкой при расширении конфигурации

2. Заменить процедуру ОбновитьРолиПользователей

Специалист компании «Кодерлайн»

Антонова Юлия.