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

Comments

dawehner’s picture

Issue tags: +VDC

+1 for the idea!

ekes’s picture

The 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?

damiankloip’s picture

Status: Active » Needs review
StatusFileSize
new14.52 KB

This 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.

Status: Needs review » Needs work

The last submitted patch, 3: 2204239.patch, failed testing.

The last submitted patch, 3: 2204239.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
StatusFileSize
new15.86 KB
new3 KB

Meh, 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?

Status: Needs review » Needs work

The last submitted patch, 6: 2204239-6.patch, failed testing.

The last submitted patch, 6: 2204239-6.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review
StatusFileSize
new22.15 KB
new7.15 KB

Let's try and get things back to a passable state.

berdir’s picture

Status: Needs review » Active

Meh, 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?

This is the same problem as we have everywhere with entity controllers/handlers, not much that we can do about it.

berdir’s picture

Status: Active » Needs review

Did not mean to set to needs review, I think the second part (drop the field definitions part), hasn't been addressed yet I think?

damiankloip’s picture

StatusFileSize
new26.01 KB
new6.28 KB
new25.37 KB

Ok, 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.

damiankloip’s picture

dawehner’s picture

  1. +++ b/core/modules/user/lib/Drupal/user/Plugin/views/argument_validator/User.php
    @@ -17,76 +17,51 @@
    -    parent::__construct($configuration, $plugin_id, $plugin_definition);
    +  public function __construct(array $configuration, $plugin_id, array $plugin_definition, EntityManagerInterface $entity_manager) {
    +    parent::__construct($configuration, $plugin_id, $plugin_definition, $entity_manager);
     
    -    $this->database = $database;
    +    $this->userStorage = $entity_manager->getStorageController('user');
    

    Nice trick!

  2. +++ b/core/modules/user/lib/Drupal/user/Plugin/views/argument_validator/User.php
    @@ -98,79 +73,29 @@ public function buildOptionsForm(&$form, &$form_state) {
    +  protected function validateEntity(EntityInterface $entity) {
     
    +    $role_check = TRUE;
    

    Can we insert something like /** @var ... UserInterface $entity */ here?

  3. +++ b/core/modules/user/lib/Drupal/user/Plugin/views/argument_validator/User.php
    @@ -98,79 +73,29 @@ public function buildOptionsForm(&$form, &$form_state) {
    +    return $role_check && parent::validateEntity($entity);
    

    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?

damiankloip’s picture

StatusFileSize
new26.34 KB
new1.71 KB

Thanks! They are fair points. Done.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Thank you!

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll

2204239-15.patch no longer applies.

error: patch failed: core/modules/user/lib/Drupal/user/Plugin/views/argument_validator/User.php:98
error: core/modules/user/lib/Drupal/user/Plugin/views/argument_validator/User.php: patch does not apply

damiankloip’s picture

Rerolling...

balintcsaba’s picture

Assigned: Unassigned » balintcsaba
balintcsaba’s picture

Assigned: balintcsaba » Unassigned
sutharsan’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
StatusFileSize
new26.44 KB

Patch #15 rerolled

damiankloip’s picture

Status: Needs review » Reviewed & tested by the community

Thank you.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs reroll

2204239-21.patch no longer applies.

error: patch failed: core/modules/user/lib/Drupal/user/Tests/Views/ArgumentValidateTest.php:7
error: core/modules/user/lib/Drupal/user/Tests/Views/ArgumentValidateTest.php: patch does not apply

damiankloip’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
StatusFileSize
new26.23 KB

Rerolled.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

it is green!

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 24: 2204239-24.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review

24: 2204239-24.patch queued for re-testing.

berdir’s picture

Status: Needs review » Reviewed & tested by the community

Random fail I guess, back to RTBC.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Very nice. Committed/pushed to 8.x, thanks!

  • Commit 4e9a885 on 8.x by catch:
    Issue #2204239 by damiankloip, Sutharsan: Simplify and de-duplicate...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.