The GitHub Actions job "CI" on grails-core.git/8.0.x has failed. Run started by GitHub user borinquenkid (triggered by borinquenkid).
Head commit for run: c1b532aef9fea7a634ba21c17b247935cb9f72c2 / Scott Murphy <[email protected]> M6 FIX: Require a username and password on the spring-boot-starter-security User (#16291) * Require a username and password on the spring-boot-starter-security User Grails 8 makes an unconstrained persistent property nullable by default (upgrading80x.adoc, "GORM Properties Are Nullable by Default"), so the template's `blank: false` constraints stopped making the credentials required: a User with a null username and a null password validated clean, and the scaffolded admin would happily save one. Every other domain template in the forge -- role, userClassic, userRole -- already declares `nullable: false`; this one was missed when the default flipped. The generated UserSpec failed out of the box for the same reason. Its `!new User(username: '', password: '').validate()` never exercised the blank constraint at all: the map constructor binds through data binding with convertEmptyStringsToNull, so both values arrived as null and then passed. Assign the blank values directly, which is the only way a blank string reaches the property, and cover the nullable case as its own feature so the two constraints are asserted separately. * Map the security User through the directive its data store understands The template emitted `table 'users'` for every data implementation, but `table` is a Hibernate directive. On MongoDB it was silently ignored, so the intent behind it -- don't name the persistence unit `user`, which is a reserved word in PostgreSQL, H2 and SQL Server -- was lost exactly where nothing warned about it. Booting a generated mongodb app showed the documents landing in a `user` collection; with `collection 'users'` they land in `users`. Pick the directive from the selected features, the way GrailsBase and DatabaseMigrationPlugin already do, rather than from the gorm option, so it holds whether the implementation was chosen with --data or by naming the feature. Hibernate 5 and 7 keep `table 'users'`, MongoDB gets `collection 'users'`, and a store that uses neither -- Neo4j -- gets no mapping block at all rather than a directive it does not understand. * Map the classic security User through the directive its data store understands The classic User/Role/UserRole domain model shared by grails-spring-security and grails-spring-security-ui hardcoded a Hibernate-only `table` mapping directive, same defect this PR already fixes for the spring-boot-starter-security User template. Neither feature is restricted to Hibernate, so selecting gorm-mongodb alongside either one silently dropped the directive. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01K4Wxz1HXEyfVWGm52jzvpR --------- Co-authored-by: Walter Duque de Estrada <[email protected]> Co-authored-by: Claude Sonnet 5 <[email protected]> Report URL: https://github.com/apache/grails-core/actions/runs/33582769966 With regards, GitHub Actions via GitBox
