anchor.diff:  .UserToRole__joe_UserRw_but_NoDelete.java
   ----
   public class UserToRole__joe_UserRw_but_NoDelete
  -        extends AbstractUserAndRolesFixtureScript {
  -
  -    public UserToRole__joe_UserRw_but_NoDelete_or_isis2619Prop() {
  -        super(
  -          "joe", "pass",                                               // <.>
  -          "joe@italy.com",                                             // <.>
  -          "/ITA",                                                      // <.>
  -          AccountType.LOCAL,                                           // <.>
  -          Can.of(
  -            RoleAndPerms__UserRw.ROLE_NAME                             // <.>
  -            , RoleAndPerms__NoDelete.ROLE_NAME                         // <5>
  -            , SecmanConfiguration.DEFAULT_REGULAR_USER_ROLE_NAME       // <.>
  -            , IsisExtH2ConsoleRoleAndPermissions.ROLE_NAME             // <.>
  -            , IsisPersistenceJdoMetaModelRoleAndPermissions.ROLE_NAME  // <7>
  -          ));
  -    }
  -}
  -----
  -<.> username and password
  -<.> email address
  -<.> application tenancy
  -<.> local account (rather than delegated, see xref:setting-up-with-shiro.adoc[])
  +    extends AbstractUserAndRolesFixtureScript {
  +
  +  public UserToRole__joe_UserRw_but_NoDelete() {
  +    super(
  +      "joe", "pass",
  +      "joe@italy.com",
  +      "/ITA",
  +      AccountType.LOCAL,
  +      Can.of(
  +        RoleAndPerms__UserRw.ROLE_NAME                                           // <.>
  +        ,RoleAndPerms__NoDelete.ROLE_NAME                                        // <1>
  +        ,IsisConfiguration.Extensions.Secman.Seed.REGULAR_USER_ROLE_NAME_DEFAULT // <.>
  +    ));
  +  }
  +}
  +----
   <.> application-specific roles
   <.> regular user access (always required)
   <.> specific access to framework features, see <<default-roles,above>>
   
  -
   To seed in fixture scripts we could create a top-level `CustomRolesAndUsers` script (as mentioned in <<custom-seed-service,above>>).
   This would then look something like:
   
  
positive.code: }
  ----
  
  * to set up a "no-delete" role that vetoes the ability to delete objects:
  +
  [source,java]
  
negative.code:     @Override protected void execute(ExecutionContext executionContext) {
          executionContext.executeChildren(this,
                  // roles
                  new RoleAndPerms__HelloRw()
                  // users
                  , new UserToRole__bob_allRoles()
                  , new UserToRole__joe_UserRw_but_NoDelete()
          );
      }
  }
  ----
  
  The custom seed service would then ensure that these users/roles existed on startup.
  
  
  == Creating Users and Roles
  
  Once a super-user admin account has been seeded in, regular users can be created manually by logging in as that security super-user.
  
  Alternatively, users can be created programmatically through xref:refguide:extensions:index/secman/applib/user/dom/ApplicationUserRepository.adoc[ApplicationUserRepository].
  This will return an xref:refguide:extensions:index/secman/applib/user/dom/ApplicationUser.adoc[ApplicationUser] which can then be granted roles, for example using `addRoleToUser()` API of xref:refguide:extensions:index/secman/applib/role/dom/ApplicationRoleRepository.adoc[ApplicationRoleRepository].
  
  
  [#user-registration-aka-sign-up]
  