Updated release notes

This commit is contained in:
Steffen Schaefer committed 2019-04-08 17:27:01 +02:00
1 parent 396467d1db
commit 59463130a5
1 file changed
+11 -9
@@ -28,21 +28,23 @@
leaderboard group containing "Apr 2" in its name is doable.
</li>
<li>In AdminConsole.html all tables and lists are now filtered to only show domain objects readable by the current user.
This means additional objects may exist and cause e.g. errors due to name conflicts.<br>
This means additional objects may exist on the server and can cause errors due to name conflicts.<br>
To allow users to grant others permissions for their stuff, it is possible to manage permissions for users whose username is known without having a read permission for that user.
In addition, users may be added to groups by only knowing their username.
</li>
<li>The permission system was extended to allow groups to directly grant roles to their users or all users (including anonymous ones) restricted to domain objects owned by that group.
With this it isn't necessary to grant the same a scoped role to every user manually, but adding a user implies this elegantly.
By associating the <tt>sailing_viewer</tt> role to a group with "for all users" enabled makes the object owned by that group publicly readable.
<li>The permission system was extended to allow groups to directly grant roles to their users.
In addition such a role can also be granted to all users (including anonymous ones).
Roles associated to groups only grant permissions to domain objects owned by that group.<br>
Example: By associating the <tt>sailing_viewer</tt> role to a group with "for all users" enabled, all objects owned by that group are publicly readable.
</li>
<li>When loading or tracking wind from Igtimi, only accounts readable by the current user will get included.
For event servers the Account should be configured in the server group to make it consistently be visible to all server admins.
<li>When loading or tracking wind from Igtimi, only accounts readable by the current user will be used.
On dedicated event servers, such an account should be owned by the server group.
This ensures, that all server admins will consistently use this account while tracking races.
</li>
<li>Replication is now also secured by several actions of the SERVER security type.
To enable permission checks on the master side, it is now necessary to provide credentials of a user on the master server that is used when a replica contacts the master.
This user at least needs to have the permission <tt>SERVER:REPLICATE:&amp;server-name&amp;</tt> granted on the master. <br>
Start scripts and documentation is updated regarding configuration of those credentials for auto replication.
Due to permission checks on the master side, it is now necessary to provide credentials of a user on the master server that is used when a replica contacts the master.
This user at least needs to have the permission <tt>SERVER:REPLICATE:&amp;server-name&amp;</tt> granted on the master.<br>
Server start scripts as well as the replication documentation have been updated to include details about configuring credentials for auto replication.
Newly created servers should automatically contain adjusted versions of the relevant scripts.
The configuration of existing servers needs to get updated accordingly.
</li>