update documentation for new behavior

diff --git a/doc/antora/modules/installation/pages/upgrade.adoc b/doc/antora/modules/installation/pages/upgrade.adoc
index 3e8931853097842c5d6f7a97f37e62f9e623df99..63751add9df9348999ec75d68cd046dfd5955de2 100644 (file)
--- a/doc/antora/modules/installation/pages/upgrade.adoc
+++ b/doc/antora/modules/installation/pages/upgrade.adoc
@@ -925,8 +925,9 @@ will return `true`.
 
 ==== Profiles
 
-The `default_user_profile` and the `User-Profile` attributes have been
-removed.  No one used them, as that behavior was already supported by the group functionality.
+The `default_user_profile` has been removed.  No one used it, as that
+behavior was already supported by the group functionality.  See
+rlm_sql and `User-Profile` for new, and superior, behavior.
 
 ==== rlm_sql_mysql
 

diff --git a/doc/antora/modules/raddb/pages/mods-available/sql.adoc b/doc/antora/modules/raddb/pages/mods-available/sql.adoc
index a48620a5f8628a2855c6e68a8fc8e8c524a572d2..dc76aab815259e5b891fc62659251474a7d617d3 100644 (file)
--- a/doc/antora/modules/raddb/pages/mods-available/sql.adoc
+++ b/doc/antora/modules/raddb/pages/mods-available/sql.adoc
@@ -291,6 +291,14 @@ The module loops over all groups, and places the group name into the "group_attr
 The group attribute is used in the "authorize_group_check_query" and "authorize_group_check_query"
 to select entries which match that particular group.
 
+After all groups in SQL have been run, the module looks for `&control.User-Profile`, and runs
+those profiles for "authorize_group_check_query" and "authorize_group_check_query".  i.e. a user
+profile is essentially a group.
+
+These group queries can also update `&control.User-Profile`, which lets you have a group
+create a "fall through" to a DEFAULT group.  However, these groups are _not_ cross-checked against
+each other.  So it is possible to create loops, which is highly not recommended.
+
 If caching is enabled, then the module is done looping over groups, the module adds the names of
 groups to the `control` list.  The "group_attribute" can then be used to check group membership.
 That check will be done internally, and will not result in a database lookup.  This also means that

diff --git a/raddb/mods-available/sql b/raddb/mods-available/sql
index 4a88b5d9e53239b538322c6c6504b048ebbfc32a..9dac4528eb588e0e58eee52bbdde7281ce80c489 100644 (file)
--- a/raddb/mods-available/sql
+++ b/raddb/mods-available/sql
@@ -329,6 +329,14 @@ sql {
        #  The group attribute is used in the "authorize_group_check_query" and "authorize_group_check_query"
        #  to select entries which match that particular group.
        #
+       #  After all groups in SQL have been run, the module looks for `&control.User-Profile`, and runs
+       #  those profiles for "authorize_group_check_query" and "authorize_group_check_query".  i.e. a user
+       #  profile is essentially a group.
+       #
+       #  These group queries can also update `&control.User-Profile`, which lets you have a group
+       #  create a "fall through" to a DEFAULT group.  However, these groups are _not_ cross-checked against
+       #  each other.  So it is possible to create loops, which is highly not recommended.
+       #
        #  If caching is enabled, then the module is done looping over groups, the module adds the names of
        #  groups to the `control` list.  The "group_attribute" can then be used to check group membership.
        #  That check will be done internally, and will not result in a database lookup.  This also means that