Bug: removeAll(User u) in UserRole empties whole table

[feuernurmitm]

Task List

• Steps to reproduce provided
• Stacktrace (if present) provided
• Example that reproduces the problem uploaded to Github
• Full description of the issue provided (see below)

Steps to Reproduce

1. Create a new Grails 4.X application
2. add compile 'org.grails.plugins:spring-security-core:4.0.3' to build.gradle
3. run grailsw s2-quickstart myapp User Role
4. create at least one role and two users, e.g. in Bootstrap.groovy:
   Role role = new Role(authority: 'ADMIN').save(); User user1 = new User(username: 'user1', password: 'abc123').save(); User user2 = new User(username: 'user2', password: 'abc123').save();
5. Attach users to roles: UserRole.create(user1, role, true); UserRole.create(user2, role, true)
6. Call UserRole.removeAll(user1) from anywhere, e.g. TestController.groovy:
   User user = User.findByUsername('user1'); UserRole.removeAll(user); user.delete()

Expected Behaviour

To my understanding UserRole.removeAll(User u) {...} should remove every UserRole entry connected to the user u.

Actual Behaviour

Instead of just one entry being deleted, the method deletes all UserRole entries in the database.

This caught my attention in the GORM for Hibernate docs:

Note that one limitation with regards to batch operations is that join queries (queries that query associations) are not allowed.

Environment Information

• Operating System: Windows 10
• GORM Version: 7.0.8.RELEASE
• Grails Version (if using Grails): 4.0.6
• JDK Version: 11

Example Application

• TODO: link to Github repository with example that reproduces the issue
• I will provide one, if necessary :)

[logantracyo]

This appears to be similar to the problem mentioned in this S2UI issue, which includes an example.

I ran into that same problem, and in the course of investigating it, discovered a workaround: Copy the plugin method to a new class extending the plugin's class -- for some reason, with no code changes, just that override makes it work as expected, deleting only the intended UserRole(s).

In case that workaround helps anyone else (including perhaps shedding some light on the cause of the problem), full details are in this comment on that S2UI issue.