Updated: Comment #N
Problem/Motivation
1. There is a generic entity validator now, but the old valdiators are still there (node, user). And they have the same labels, that's pretty confusing.
2. The code uses 2 different bundle labels, the defined bundle label and and label of the field that is the bundle, trying to come up with a description that makes sense, but it doesn't really work due to singular/plural anyway: "Restrict to one or more Type. If none selected all are allowed.".
Proposed resolution
1. Completely duplicated validators should be excluded, we should not have duplicate labels which we currently have for User, Content. taxonomy does alter it in taxonomy_views_plugins_argument_validator_alter().
2. I'd suggest to only use the official bundle label and possibly rewrite the description or leave the first part out completely or always hardcode bundle. Could simplify the code there quite a bit.
Remaining tasks
User interface changes
API changes
| Comment | File | Size | Author |
|---|---|---|---|
| #24 | 2204239-24.patch | 26.23 KB | damiankloip |
| #6 | interdiff-2204239-6.txt | 3 KB | damiankloip |
| #6 | 2204239-6.patch | 15.86 KB | damiankloip |
Comments
Comment #1
dawehner+1 for the idea!
Comment #2
ekes commentedThe old node argument validator doesn't add any functionality, and so can be removed.
The old user argument validator offers authentication of a single argument of type id, name or both. It also adds filter by role.
[
Notes about this:
If someone has a numeric username, that is also a UID, the numeric username will trump the UID if 'either' is on;
If the UID have gone beyond integer range of the system the UID validation will fail because it compares a cast to integer; I've not even thought about usernames starting with '0' or '0x';
I think I read a bug in the present version that means if the argument being validated is the global $user, the $uid doesn't get set which is then used to reload the user into $account that is actually validated against
].
The Entity user argument validator offers authentication of single or multiple id arguments. It does not filter by role.
The consistent thing to do, consistent with Taxonomy Term would be to split it into ID only and Name only validators (both extended simply on the Entity one - adding the role filtering). This would avoid anomalies, but remove 'either' functionality.
Less consistent, and a little more complicated would be to maintain the mixed functionality, as one validator.
Latter or former?
Looks like just having two clean ID and Name validators, and not a the mixed one, would be best?
Comment #3
damiankloip commentedThis is by no means a finished patch, we could do something like this though?
Made better user of the Entity argument validator plugin, as we can greatly reduce the code in the user classes for validating the actual entity, just extending validateEntity to add our additional check for user roles.
Comment #6
damiankloip commentedMeh, I didn't match up the method signatures for validateEntity() in haste. Have changed now to EntityInterface. This is not ideal as getUserName() and friends is not on EntityInterface BUT the only entities using this plugin will be users...thoughts?
Comment #9
damiankloip commentedLet's try and get things back to a passable state.
Comment #10
berdirThis is the same problem as we have everywhere with entity controllers/handlers, not much that we can do about it.
Comment #11
berdirDid not mean to set to needs review, I think the second part (drop the field definitions part), hasn't been addressed yet I think?
Comment #12
damiankloip commentedOk, moved that around as suggested, and simplified that part of the form. I think it is much better now - good idea berdir!
Made a couple of other small tweaks too while I was there..
Also, attached screenshot of bundle validation radio buttons for content.
Comment #13
damiankloip commentedComment #14
dawehnerNice trick!
Can we insert something like /** @var ... UserInterface $entity */ here?
the variable name is kinda odd. I would have expect that this would enabling the checking of the role. maybe just role_check_success or something similar?
Comment #15
damiankloip commentedThanks! They are fair points. Done.
Comment #16
dawehnerThank you!
Comment #17
alexpott2204239-15.patch no longer applies.
Comment #18
damiankloip commentedRerolling...
Comment #19
balintcsaba commentedComment #20
balintcsaba commentedComment #21
sutharsan commentedPatch #15 rerolled
Comment #22
damiankloip commentedThank you.
Comment #23
alexpott2204239-21.patch no longer applies.
Comment #24
damiankloip commentedRerolled.
Comment #25
dawehnerit is green!
Comment #27
damiankloip commented24: 2204239-24.patch queued for re-testing.
Comment #28
berdirRandom fail I guess, back to RTBC.
Comment #29
catchVery nice. Committed/pushed to 8.x, thanks!