Update from OpenOlat 8.1.4 to OpenOlat 8.2.x

1. Stop Tomcat
2. Backup
   • your olatdata, your webapps directory and make a database dump
   • your olat.local.properties file
   • your entire webapps-Directory of OpenOLAT, then delete it
3. Extract OpenOlat.war in the webapps-location (replace old release)
4. If you have not yet installed OpenOLAT 8.1.4, you must run the DB-updatescripts. If you have 8.1.4 already installed, skip this step
   • manually by executing src/main/resources/database/mysql/alter_8_1_x_to_8_2_0.sql
   • or make sure you have the property auto.upgrade.database=true (recommendet)
   • If you use MySQL, make sure you use MySQL 5.5 or above and not 5.1! OpenOLAT uses view that can have a severe performance issue with MySQL 5.1!
5. Copy your old olat.local.properties file to the new unpacked war (or wherever you have it)
6. Compare your olat.local.properties with the olat.local.properties.sample and the original olat.properties file
7. If you have a custom theme copy it over to the new installed release
8. If you have custom spring configurations, re-apply them on the new code base (do not just copy the old spring files as they might have changed! Use the diff command to compare the old and the new files).
9. Restart tomcat and look at your console output (e.g. tail -f)
   • First startup might take a while because some stuff is migrated.
   • Do NOT shutdown until OpenOLAT did the initial startup!
10. Fix the wrong group manager permissions using the queries below
11. In the sys admin section, go to the group configuration and press the "purge course members" button. This will search for users in courses that are course members and also members of groups of the same courses. Those duplicates are deleted. If unsure it is also possible to perform this action on the per-course level in the course member management. (available since 8.2.1)
12. Check if you have groups with names that clash identical to user properties that might lead to wrongly migrated course expert rules. See query below.
13. Let everybody know you just updated to OpenOLAT 8.2.0 (twitter, facebook etc)
14. Go get a beer and have fun!

Group manager permissions cleanup

In previous versions of OpenOLAT a so-called course comprehensive groupmanagement was available. Users with the groupmanagement permission could start this environment. Those users are users that have the group managmenet role assigned in the usermanagmenet. However, as you can give someone author permissions by adding him to the owner group of a course, you can also give someone groupmanagement permissions by adding a user to the owner group of such a course comprehensive group context. Those users will not show up as group managers in the usermanagement!

This was very confusing, and somethings people were put as owners of a group context instead of the real groups. But by adding them there, those users got implicit group management rights.

In 8.2.x those implicit group management rights must all be removed as those users do not show up as real group managers in the usermanagement.

Do the following and copy the list of users somewhere:

• Run this statement to find group context owners:

select distinct identity.name from o_bs_membership as membership
inner join o_bs_identity as identity on (membership.identity_id = identity.id)
where membership.secgroup_id in
  (select policy.group_id from o_bs_policy as policy, o_olatresource as resource
     where   policy.oresource_id = resource.resource_id and policy.permission='hasRole'
     and     resource.resname='BaseSecurityModule:RGroupmanager'
  )                                                                                         

• Run the delete statement to delete those implicit group management rights:

delete from o_bs_membership
where secgroup_id in                                                          
  (select policy.group_id from o_bs_policy as policy, o_olatresource as resource
     where   policy.oresource_id = resource.resource_id and policy.permission='hasRole'
     and     resource.resname='BaseSecurityModule:RGroupmanager'
  )                                                                                                                                          
  and secgroup_id not in (select namedgroup.secgroup_id from o_bs_namedgroup as namedgroup);

• In the user management have a look at the list of group managers and add all the users from the previous list that are missing and that should have full access to all groups in the entire system

Course expert rule migration check

The 8.2 update will migrate all courses to not contain group names anymore but rather replace them with the ID of the corresponding group. This is done using the plain vanilla search-replace mechanism. However, if you have an hasAttribute rule in the same course that checks for an attribute with the exact same name as an existing group of that course, this attribute rule will be modified as well.

This is wrong. As this is a very rare case you have to fix this yourself. Using the query below you can check if you have any groups that have the same name as a user property. If this is not the case you will most likely be save. If you find some groups, you might want to look them up and check all associated courses and see if they use any hasAttribute rule. The problem happens really only when both conditions are true.

select prop.propname as prop_name, prop.propvalue as prop_value, grp.groupname as groupname
from o_userproperty as prop, o_gp_business as grp
inner join o_gp_business_to_resource grp_rsrc on (grp_rsrc.fk_group=grp.group_id)
where prop.propvalue=grp.groupname 
group by prop.propname, prop.propvalue, grp.groupname