Review of Chapter 10

Author: lcharette

app/pages/6.0/10.users/01.user-accounts/docs.md

@@ -1,7 +1,6 @@
 ---
 title: User Accounts
 description: UserFrosting ships with everything you need to create user accounts, and a rich set of features for users and administrators.
-wip: true
 ---
 
 You were probably attracted to UserFrosting because you wanted to "make a site where users can sign in", or you already have a project in progress and your boss asked you to "put it behind a login," or you need to have some "protected pages." These are nontechnical terms. It will be easier for us to communicate if we first establish a common vocabulary, so that we can explain the concepts with more precision.
@@ -62,6 +61,7 @@ UserFrosting comes with two built-in mechanisms for creating new accounts: publi
 
 In many instances, you will want people to be able to register for your website or application through a publicly accessible page. By default, the registration form is available at `/account/register`.
 
+<!-- TODO : Update image -->
 ![Account registration form](/images/registration.png)
 
 When the registration form is submitted, it will `POST` to the `/account/register` endpoint (which invokes the `RegisterAction` method).
@@ -89,16 +89,19 @@ To disable this behavior, set the `site.registration.require_email_verification`
 
 Sometimes, you want to have a site administrator create an account on behalf of a specific user. For some applications, you may want this to be the _only_ way that new accounts can be created. To create a new user as an administrator, use the "create user" button at the bottom of the main user listing page:
 
+<!-- TODO : Update image -->
 ![User creation button](/images/create-user-button.png)
 
 You can then fill out details for the user. After you create the user, an email will be automatically sent to them that allows them to set their own password.
 
+<!-- TODO : Update image -->
 ![User creation](/images/create-user.png)
 
 ## Login form
 
 By default, the login form is available at `/account/sign-in`. The user provides their email or username as their identity, along with their password. The form is submitted to `/account/login`, which invokes `LoginAction`. This processes the authentication request.
 
+<!-- TODO : Update image -->
 ![User sign-in](/images/login.png)
 
 The `/account/login` route is throttled via the `throttles.sign_in_attempt` throttle rule. This mitigates against the possibility of brute-force attempts to guess your users' passwords.
@@ -123,6 +126,7 @@ After the page containing the sign-in form receives a response from the server t
 
 Users can reset their passwords by visiting `/account/forgot-password`. They will be asked for their account email address:
 
+<!-- TODO : Update image -->
 ![Password reset](/images/password-reset.png)
 
 Upon submitting a password reset request, a secret token will be issued for the user's account (stored in `password_resets` table), and emailed to them in the form of a link (`/account/set-password/confirm`). The link will take them to a form with the secret token embedded in the page, where they can set their new password. The form is then submitted to `/account/set-password`, which updates the user's password and signs them in.
@@ -143,6 +147,7 @@ For the precise implementation of the password reset and account verification re
 
 Users can update certain attributes of their accounts through the account settings/profile page. By default, this is available at `/account/settings`:
 
+<!-- TODO : Update image -->
 ![Account settings page](/images/account-settings.png)
 
 As a security measure, users are required to verify their current password before they can update their email address or password. Other fields, like name and locale, do not require the authenticated user to re-enter their password.
@@ -194,6 +199,7 @@ Basic user details (name, email, locale, group) can be modified via the "Edit us
 
 Roles can be added to or removed from a user account via the `Manage roles` button on the user's profile page, or in the dropdown menu in the user table.
 
+<!-- TODO : Update image -->
 ![User role management](/images/uf-collection.png)
 
 By default, only the root account can change users' roles. You may want to modify this to allow site admins to grant a **subset** of the available roles to other users - but be careful! You may not want site administrators to be allowed to elevate other users to site administrator, for example. See the section on [access control](/users/access-control) for more information.
@@ -202,6 +208,7 @@ By default, only the root account can change users' roles. You may want to modif
 
 Administrators may be able to perform a password reset on behalf of users. This is useful, for example, when you have users who have difficulty with the self-service password reset tool. Password resets can be performed via the "Password" button in the user's profile page, or the "change password" option in the dropdown menu of the user table.
 
+<!-- TODO : Update image -->
 ![User password management](/images/change-password.png)
 
 You may send a password reset link to the user so that they can change it themselves, or even set a password directly when dealing with particularly technology-adverse users over the phone.

app/pages/6.0/10.users/02.access-control/docs.md

@@ -1,7 +1,6 @@
 ---
 title: Authorization
 description: Authorization is sometimes referred to as "access control" or "protecting pages". UserFrosting implements an extended version of role-based access control that supports procedural conditions on user permissions.
-wip: true
 ---
 
 Authenticating users (knowing who they are) is only half the battle. The harder question is: **what should each user be allowed to do?** Not every user should access administrative features, delete data, or view sensitive information. Without proper authorization, your application becomes either a security hole (everyone can do everything) or a maintenance nightmare (hardcoded permissions scattered everywhere).

app/pages/6.0/10.users/03.groups/docs.md

@@ -1,7 +1,6 @@
 ---
 title: Groups
 description: Unlike roles, which assign specific sets of permissions to users, user groups allow you to horizontally partition your users.
-wip: true
 ---
 
 Every user can belong to **exactly one group**. Groups are used to horizontally partition your users - for example, if you have offices in Baltimore, London, and Munich, you might want to group your users according to which office they are in. Group membership can be used to broadly determine styling, layout, or access control for all users in the group.

app/pages/6.0/10.users/04.activity-logging/docs.md

@@ -1,7 +1,6 @@
 ---
 title: Activity Logging
 description: The activity logger allows you to capture and log user activities. By default this information is sent to the database, but you can use Monolog to customize how this information is stored - even having critical activity alerts sent to an administrator!
-wip: true
 ---
 
 By default, user activities are logged to the `activities` database table. Logged information includes the activity time and an activity type, the `user_id`, the user's IP address, and a description of the activity. The administrative interface provides convenient tables for viewing these logs:
@@ -16,20 +15,23 @@ The following activity types are logged by the core UserFrosting features:
 |---------------|-------------|
 | `sign_up` | The user signed up via the public registration page. |
 | `sign_in` | The user signed in to their account. |
+| `sign_out` | The user explicitly signed out of their account (note, this does not capture when a user's session expires on its own). |
+| `verified` | The user verified their email address. |
+| `password_reset` | The user reset their password. |
+| `password_upgraded` | The user's password hash was automatically upgraded to modern hashing. |
 | `update_profile_settings` | The user updated their profile settings (name, locale, etc). |
 | `update_account_settings` | The user updated their account settings (email or password). |
-| `sign_out` | The user explicitly signed out of their account (note, this does not capture when a user's session expires on its own). |
 | `group_create` | The user created a new group. |
 | `group_delete` | The user deleted a group. |
-| `group_update_info` | The user updated information for a group. |
+| `group_update_info` | The user updated the details of a group. |
 | `role_create` | The user created a new role. |
 | `role_delete` | The user deleted a role. |
-| `role_update_info` | The user updated general information for a role. |
+| `role_update_info` | The user updated the details of a role. |
 | `role_update_field` | The user updated a specific attribute of a role (this includes modifying the permissions for a role). |
 | `account_create` | The user created an account for another user. |
 | `account_delete` | The user deleted another user's account. |
-| `account_update_info` | The user updated general account info (name, locale, etc) for another user. |
-| `account_update_field` | The user updated a specific field for another user (this includes modifying a user's roles or password, and enabling/disabling their account). |
+| `account_update_info` | The user updated basic account info for another user (name, email, locale, group). |
+| `account_update_field` | The user updated a specific field for another user account (e.g., enabled/disabled status, verification status, password, roles). |
 
 > [!NOTE]
 > These activities are only logged _when successful_. If a user is unable to perform one of these activities, for example because they don't have the necessary permissions or there is some other problem, the attempt won't be logged.

app/pages/6.0/10.users/chapter.md

@@ -1,7 +1,6 @@
 ---
 title: Users
 description: In this chapter, you'll learn about the various user account features that come built-in and fully implemented in UserFrosting.
-wip: true
 ---
 
 #### Chapter 10