Как правильно использовать отношения Parse.Roles для нескольких объектов Parse.Objects и Users с течением времени? - PullRequest
0 голосов
/ 29 сентября 2018

Большая часть следующего выполняется с помощью parse-dashboard, так что это немного многословно, но я понимаю код, а не отношения.

Я устанавливаю Parse.Roles и похоже, что каждый отдельный ParseДля объекта .Object должна быть установлена ​​роль, чтобы иметь доступ к данному объекту Parse.Object.Например, объектный ACL-список должен содержать как «Admin», так и «Moderator» (с соответствующими разрешениями), чтобы администраторы или модераторы имели доступ.

Поскольку родительские и дочерние роли возможны, имеет смысл установить ACL Parse.Object с ролью «Organization», которая затем дополнительно изменяется дочерней ролью.Таким образом, «Средство просмотра» в «Организации» не может писать, а «Администратор» в «Организации» может читать / писать.Я попробовал несколько способов сделать это - привязать одного пользователя к «Средству просмотра», а другого - к «Администратору» внутри «Организации», но это, похоже, не работает.

Мое текущее решение: Чтобы вручную / программно установить каждый Parse.Object ACL с несколькими предустановленными ролями.Например, Parse Class "Person" с ролями ACL "Viewer" и "Admin".

Вопрос: Если я хочу создать другую Роль в будущем для этой же Организации, мне нужно будет перебрать каждый объект Parse.Object и вручную установить новую Роль для каждого изПрошлые объекты?

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

Любые ответы, мысли или ссылки приветствуются.

1 Ответ

0 голосов
/ 30 сентября 2018

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

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

Я приведу вам пример:

Допустим, у вас есть класс с именем Posts.

  • у вас есть имя роли viewer, иу вас есть роль с именем editor.

  • , когда вы создаете новый объект публикации, вы добавляете обе роли viewer и editor в качестве ACL объекта записи.Например, роль просмотра может иметь только права на чтение, а редактор может иметь права как на чтение, так и на запись.

Для каждой организации:

  • Сначала вы создаетеимя роли uniqueOrganizationName
  • Затем вы добавляете всех пользователей, принадлежащих к этой организации, к uniqueOrganizationName пользователям (отношение).

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

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

  • создайте две уникальные роли для каждой организации viewUniqueOrganizationRole & editUniqueOrganizationRole.

Теперь, когда вы создаете новую запись, в зависимости от того, к какой организации принадлежит эта запись, вы добавляете viewUniqueOrganizationRole && editUniqueOrganizationRole в ACL объекта записи.

  • Послетаким образом, вы можете добавить пользователей к viewUniqueOrganizationRole, чтобы иметь возможность просматривать сообщения, принадлежащие этой организации, или вы можете добавить пользователей к editUniqueOrganizationRole, чтобы они могли редактировать ваше сообщение.

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

...