Merge pull request #137 from StrykeSlammerII/patch-1

userfrosting · Apr 3, 2024 · f63d9fe · f63d9fe
2 parents 619d632 + e46eb65
commit f63d9fe
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 4 deletions.
diff --git a/pages/10.users/02.access-control/docs.md b/pages/10.users/02.access-control/docs.md
@@ -57,7 +57,7 @@ if (!$this->authorizer->checkAccess($currentUser, 'uri_users')) {
 }
 ```
 
-Or simply use the `checkAccess` method of the `Authenticator` service, which is a shortcut for the above code (the current user will be automatically passed to `AuthorizationManager` behind the scene). For example:
+Or simply use the `checkAccess` method of the `Authenticator` service, which is a shortcut for the above code (the current user will be automatically passed to `AuthorizationManager` behind the scenes). For example:
 
 ```php
 #[\DI\Attribute\Inject]
@@ -184,9 +184,9 @@ Think about it this way - for a permission to have any effect on your applicatio
 
 Instead, you should think of permissions as hardcoded parts of your application that just happen to be stored in the database. Permissions can be **added, removed, or modified** using a [database migration](/database/migrations) or a [database seed](/database/seeding).
 
-Both methods can be used to create or manipulate permissions. **Migrations** are better suited to edit or remove existing permissions since they assure your permissions stays constant in time, but won't help you restore a permission if one gets deleted by accident, since a migration can only be run once. **Seeds** on the other hand can be run more than once, so they can be used to restore a deleted permission, but can't be relied on to edit a permission the same way you can with a migration, since a seed can be run in any order, you can't keep track which one have been run, don't have dependencies and can't be automatically rolled down.
+Both methods can be used to create or manipulate permissions. **Migrations** are better suited to edit or remove existing permissions since they assure your permissions stay constant in time. They won't help you restore a permission if one gets deleted by accident, since a migration can only be run once. **Seeds** on the other hand can be run more than once, so they can be used to restore deleted permissions, but can't be relied on to edit a permission the same way you can with a migration. Seeds can be run in any order, don't have dependencies, can't be automatically rolled down, and the system tracks neither *when* they run nor *whether* they have been run.
 
-With this in mind, it is recommended to use a **migration** to create permissions. However, since both methods are valid and can be used depending on the developer choice, both are shown below.
+With this in mind, it is recommended to use a **migration** to create permissions. However, since both methods are valid and can be used depending on the developer's choice, both are shown below.
 
 ### Using a Seed
 

diff --git a/pages/10.users/03.groups/docs.md b/pages/10.users/03.groups/docs.md
@@ -16,4 +16,4 @@ To set the default group for newly registered users, use the `site.registration.
 
 Groups are not directly associated with roles or permissions. A user in Baltimore and a user in London could have the exact same roles, but be in different groups. However, group membership can still influence a user's effective permissions _indirectly_ through a permission's [access conditions](/users/access-control#Accessconditions).
 
-For example, consider the default permission `view_group_field` with condition `equals_num(self.group_id,group.id) && in(property,['name','icon','slug','description','users'])`. A Baltimore user and the London user might both have this same permission, for example through the "Group Administrator" role.  But since the condition requires that the user's `group_id` match the target `group.id`, the Baltimore user will only end up being able to see group fields for the Baltimore group, and the London user will only be able to see group fields for the London group.
+For example, consider the default permission `view_group_field` with condition `equals_num(self.group_id,group.id) && in(property,['name','icon','slug','description','users'])`. A Baltimore user and a London user might both have this same permission, for example through the "Group Administrator" role.  But since the condition requires that the user's `group_id` match the target `group.id`, the Baltimore user will only see group fields for the Baltimore group, and the London user will only see group fields for the London group.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -16,4 +16,4 @@ To set the default group for newly registered users, use the `site.registration.

		Groups are not directly associated with roles or permissions. A user in Baltimore and a user in London could have the exact same roles, but be in different groups. However, group membership can still influence a user's effective permissions _indirectly_ through a permission's [access conditions](/users/access-control#Accessconditions).

		For example, consider the default permission `view_group_field` with condition `equals_num(self.group_id,group.id) && in(property,['name','icon','slug','description','users'])`. A Baltimore user and the London user might both have this same permission, for example through the "Group Administrator" role. But since the condition requires that the user's `group_id` match the target `group.id`, the Baltimore user will only end up being able to see group fields for the Baltimore group, and the London user will only be able to see group fields for the London group.
		For example, consider the default permission `view_group_field` with condition `equals_num(self.group_id,group.id) && in(property,['name','icon','slug','description','users'])`. A Baltimore user and a London user might both have this same permission, for example through the "Group Administrator" role. But since the condition requires that the user's `group_id` match the target `group.id`, the Baltimore user will only see group fields for the Baltimore group, and the London user will only see group fields for the London group.