StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19995229
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2013-11-15T06:54:48.247
FavoriteCount
0
LastActivityDate
2013-11-15T06:54:48.247
LastEditDate
LastEditorUserId
0
OwnerUserId
570009
ParentId
19992747
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
My answer might not shed much of a new light on the problem: Eventually, the application cannot guess who is allowed to do each operation. You'll have to tell Yii who is allowed to do what action - this way (which might be longer) or the other way (which may be shorter). You can do this in the 'long way', which is adding a 'checkAccess()' in the beginning of each action method, and reacting with a custom message if the user does not have the access. Note that this way, even if long, is verbose and clean, which leads to easier maintenance of the code. You can also utilize, as you point out, 'access control filter' with a '<a href="http://www.yiiframework.com/doc/guide/1.1/en/topics.auth#access-control-filter" rel="nofollow">accessRules</a>' method. That's shorter, but less clear to an outsider (which can be you, after a few months away from that mental area of the code), hence the code is less maintainable, IMHO. I do want to point out that using the 'access control filter' with RBAC does NOT contradict or undermines a very nice permission's hierarchy. Remember that this hierarchy comprises of roles that inherit from each other, and each role comprising tasks and possibly operations (YMMV. I typically do roles that inherit from each other, and each role is "comprised" of tasks, some of which have bizrules). If you can elaborate more why do you think this will "defeat the purpose of having a role>task>operation hierarchy" that can be fruitful for this discussion.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PORBAC in Yii - access checking
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USBoaz Rymland
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. COI agree that the checkAccess() in each action is probably the most maintainable and easiest to read, it's just a bit of a pain having to do it manually. Ideally if doing this again and planning on RBAC from the start, I think I could probably edit the template to get Gii to include the check automatically. I've edited the question to try to clarify my issue with adding roles via accessRules - basically to me it seems that it duplicates/conflicts with the work I've already done defining a role hierarchy in the database.
 singulars
 PostPostId
 PO
 UserUserId
 USMick O'Hea

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.