I ran into an issue where users weren't being locked out in cases where we were expecting them to be. After some debugging, I realized that the limits weren't being applied in hierarchical order. Instead, the module currently applies the highest limit, rather than the most specific.

For example, if the following limits are in place for a particular user… default: 10, role: 5, user: 1 …the limit in effect for that user is 10. I would have expected it to be 1, given that a user limit is the most specific.

I'm attaching a patch that applies the limits in order of hierarchy. After the patch, user limits will have the highest precedence, then roles, then the default.

Comments

johnennew’s picture

Status: Active » Needs review
StatusFileSize
new5.13 KB

I agree that any user override should take precedence to role and default.

A modified patch with some coding improvements, comments and tests.

deekayen’s picture

I'm thinking those check_plain()s might be unnecessary.

johnennew’s picture

I was worried there might have been a historical reason... how about a cast to int

johnennew’s picture

Version: 7.x-2.x-dev » 6.x-2.x-dev

committing to 7.x-2.x, changing to 6.x-2.x for backport

johnennew’s picture

backport attached.

johnennew’s picture

Status: Needs review » Fixed

committing to 6.x-2.x

Status: Fixed » Closed (fixed)

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