Problem/Motivation
Im trying to deny certain combination of user roles while creating or editing a user.
For this purpose I created a Constraint that should check whether the entered combination of roles is allowed. After implementing this, I experienced that the ConstraintValidator is executed, but the violation is not honoured by the underlying routines.
Steps to reproduce
To verify that my Contraint implemantation is correct, I added the same Constraint to the name and mail field in the same form. On this fields the Constraint works as expected. Im not sure whether I missed something, but my implementation seems to be correct as it's working on the other fields.
---- htdocs/modules/my_module/src/Plugin/Validation/Constraint/UserRolesConstraint.php ----
<?php
namespace Drupal\my_module\Plugin\Validation\Constraint;
use Symfony\Component\Validator\Constraint;
/**
* Class UserRolesConstraint
*
* @Constraint(
* id = "UserRoles",
* label = @Translation("User roles restrictions",context = "Validation")
* )
*
*/
class UserRolesConstraint extends Constraint{
public $ClientMustHaveOnlyOneGroup = 'Invalid roles selection.';
}
---- htdocs/modules/my_module/src/Plugin/Validation/Constraint/UserRolesConstraintValidator.php ----
<?php
namespace Drupal\my_module\Plugin\Validation\Constraint;
use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;
/**
* Class UserGroupConstraintValidator
*
* @package Drupal\my_module\Plugin\Validation\Constraint
*/
class UserRolesConstraintValidator extends ConstraintValidator {
/**
* @inheritdoc
*/
public function validate($value, Constraint $constraint) {
$this->context->addViolation( $constraint->ClientMustHaveOnlyOneGroup);
}
}
---- htdocs/modules/my_module/my_module.module ----
/**
* Implements hook_entity_base_field_info_alter().
*/
function my_module_entity_base_field_info_alter(&$fields, EntityTypeInterface $entityType) {
if ($entityType->id() == 'user') {
$fields['roles']->addConstraint('UserRoles');
$fields['name']->addConstraint('UserRoles');
$fields['mail']->addConstraint('UserRoles');
}
}
Attached is a screen shot of the result, I would have expected the the 'Roles' were marked as error as well.

Proposed resolution
Trigger Constraint violations for Roles on a user's account form
Remaining tasks
- Write a merge request
- Review
- Commit
User interface changes
Errors are now shown when there are constraint violations that apply to the assigned roles for a user.
Introduced terminology
None
API changes
None
Data model changes
None
Release notes snippet
None
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3055319-nr-bot.txt | 91 bytes | needs-review-queue-bot |
| Bildschirmfoto vom 2019-05-17 08-05-24.png | 49.39 KB | mmbk |
Issue fork drupal-3055319
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3055319-roles-constraint-violations
changes, plain diff MR !11317
Comments
Comment #7
cilefen commentedI am closing this support request because there have been no recent comments.
The Drupal Core issue queue is not the ideal place for support requests. Consider other sources of support.
Comment #8
abelassI have the same issue
Comment #9
idebr commentedConfirmed the issue still occurs in 11.x
Comment #11
idebr commentedThe merge request adds 'roles' to AccountForm getEditedFieldNames() and flagViolations(), so Constraint violations are properly displayed as form errors.
Comment #12
smustgrave commentedThank you for starting this with test coverage!
Issue summary appears to be missing sections, would recommend adding back specifically steps and proposed solution. Other sections can be NA if it doesn't apply
Comment #13
idebr commentedThe issue summary is updated with the issue summary template headings.
Comment #14
eelkeblokWe applied this in our project and it does the job. Seems good to go to me.
Comment #15
catchOne comment on the test coverage.
Comment #16
idebr commented\Drupal:state()is now replaced with\Drupal::keyvalue('user_form_test')in the test coverageComment #17
smustgrave commentedFeedback appears to be addressed.
Comment #18
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #19
idebr commentedUpdated merge request after #3493122: Users are able to block themselves from Drupal was committed
Comment #20
smustgrave commentedRestoring previous status.
Comment #21
quietone commentedI didn't find any unanswered questions or other work to do. I updated credit.
Leaving at RTBC.
Comment #24
larowlanCommitted to 11.x and backported to 11.2.x
Nice find folks, really clean fix too