Univention Bugzilla – Bug 40901
Computerroom unexpectedly removes exam status
Last modified: 2016-12-22 11:48:58 CET
A customer reported that a teacher started an exam and did some changes to the room settings and afterwards the exam was no longer shown in computerroom module. But all computers were still member of the special exam group and also all exam users did still exist. For the teacher there is no chance to stop the running exam. In UCS@school 4.1 it was reproducible via: 1) open the computerroom and open a room 2) start a new exam via the exam wizard for the room, previously selected in computerroom module 2a) use the "jump to computerroom" button 3) the computerroom still shows the room but does not show that there is an running exam. The view looks like a "normal room". 4) edit room settings (reset all settings to default) and then save → internal status is now broken By performing step 2a) the computerroom module does not reload the current status of the computerroom and is therefore unaware of the exam. When changing the computerroom setting, the UMCP command "computerroom/settings/set" is called and removes the status from roomInfo file. See log file /var/log/univention/management-console-module-computerroom.log: 15.03.16 11:43:14.715 PARSER ( INFO ) : UMCP REQUEST 145803859467386-34144 parsed successfully 15.03.16 11:43:14.715 MODULE ( INFO ) : Received request 145803859467386-34144 15.03.16 11:43:14.715 PROTOCOL ( INFO ) : Received UMCP COMMAND REQUEST 145803859467386-34144 15.03.16 11:43:14.715 MODULE ( INFO ) : Executing ['computerroom/settings/set'] 15.03.16 11:43:14.731 MODULE ( INFO ) : unsetting room settings for exam (test3): /usr/share/ucs-school-umc-computerroom/ucs-school-deactivate-rules -r samba/sharemode/room/Raum1 -r proxy/filter/room/Raum1/rule -e samba/othershar es/hosts/deny -e samba/share/Marktplatz/hosts/deny -e proxy/filter/room/Raum1/ip 10.200.18.10 15.03.16 11:43:21.522 MODULE ( INFO ) : iTALC users: 15.03.16 11:43:21.522 MODULE ( INFO ) : Reloading cups 15.03.16 11:43:22.515 MODULE ( INFO ) : updating room info/lock file... 15.03.16 11:43:22.516 MODULE ( INFO ) : Writing info file for room "cn=gsmitte-Raum1,cn=raeume,cn=groups,ou=gsmitte,dc=nstx,dc=local": {'examDescription': None, 'exam': None, 'room': 'cn=gsmitte-Raum1,cn=raeume,cn=groups,ou=gsmit te,dc=nstx,dc=local', 'examEndTime': None, 'cmd': None, 'pid': 26298, 'user': 'uid=Administrator,cn=users,dc=nstx,dc=local'} 15.03.16 11:43:22.516 PROTOCOL ( INFO ) : Sending UMCP RESPONSE 145803859467386-34144 The room info file now contains no trace of a running exam: root@master63:/var/cache/ucs-school-umc-computerroom# cat gsmitte-Raum1 examDescription=test3 exam=test3 room=cn=gsmitte-Raum1,cn=raeume,cn=groups,ou=gsmitte,dc=nstx,dc=local examEndTime=11:25 cmd=/usr/share/ucs-school-umc-computerroom/ucs-school-deactivate-rules -r samba/sharemode/room/Raum1 -r proxy/filter/room/Raum1/rule -e samba/othershares/hosts/deny -e samba/share/Marktplatz/hosts/deny -e proxy/filter/room/Raum1/ip 10.200.18.10 pid=26298 user=uid=Administrator,cn=users,dc=nstx,dc=local root@master63:/var/cache/ucs-school-umc-computerroom# cat gsmitte-Raum1 room=cn=gsmitte-Raum1,cn=raeume,cn=groups,ou=gsmitte,dc=nstx,dc=local pid=26298 user=uid=Administrator,cn=users,dc=nstx,dc=local root@master63:/var/cache/ucs-school-umc-computerroom# In ucs-school-umc-computerroom/umc/python/computerroom/__init__.py the function settings_set(self, request) uses the room info file for removing the room setting but then uses the "exam" argument provided by the UMCP request for writing a new room info file. Since the frontend uses outdated information, the exam status gets lost.
UCS@school 4.0 R2 is out of maintenance. Moving TM.
*** Bug 40902 has been marked as a duplicate of this bug. ***
There is now an explicit UMC request for finishing the exam. The computerroom module reuses the currently set room-values when changing settings. ucs-school-umc-computerroom.yaml: r74674 | YAML Bug #40901 ucs-school-umc-exam.yaml: r74674 | YAML Bug #40901 ucs-school-umc-computerroom (8.0.10-1): r74672 | Bug #40901: prevent removing exam state if the javascript frontend does not know about an currently written exam ucs-school-umc-exam (6.0.9-1): r74673 | Bug #40901: fix loading of exam state if the computerroom module is already opened
OK: manual test following steps above OK: automated tests 90_ucsschool/*room* (11_squidguard_assign_rule_to_2_rooms 21_computerroom_module_base_checks, 22_computerroom_*, 25_room_management_module) OK: advisory REOPEN: 1.: If I open a room in the room-module in a browserA and then start an exam in browserB, then change settings in brwoserA, the exam is removed from the room information. I can then start a 2nd exam in the same room. 2.: If I click "Finish" exam, it does trigger the expected functions, but the progress bar in the UMC doesn't go away after "Removing exam accounts - finished...". I have to forcefully close the module (button arrow up, close button) to keep working.
> 1.: If I open a room in the room-module in a browserA and then start an exam > in browserB, then change settings in brwoserA, the exam is removed from the > room information. I can then start a 2nd exam in the same room. We should fix this, too. 2mins ago, I heard from a support case that would be explainable by this. > 2.: If I click "Finish" exam, it does trigger the expected functions, but > the progress bar in the UMC doesn't go away after "Removing exam accounts - > finished...". I have to forcefully close the module (button arrow up, close > button) to keep working. Please fix this, too.
ucs-school-umc-computerroom (8.0.14-1): r75079 | Bug #40901: fix exam starting/finishing when multiple browsers are involved ucs-school-umc-exam (6.0.10-3): r75078 | Bug #40901: fix exam starting/finishing when multiple browsers are involved (In reply to Daniel Tröder from comment #4) > 1.: If I open a room in the room-module in a browserA and then start an exam > in browserB, then change settings in brwoserA, the exam is removed from the > room information. I can then start a 2nd exam in the same room. Yes, I now check in every computerroom/update-call which settings are defined. The header is automatically updated. Also the settings dialog is not anymore able to change exam settings. This has been achieved by implementing start and stop as explicit UMC calls. > 2.: If I click "Finish" exam, it does trigger the expected functions, but > the progress bar in the UMC doesn't go away after "Removing exam accounts - > finished...". I have to forcefully close the module (button arrow up, close > button) to keep working. Yes, fixed too. The code still has some theoretical issues when multiple browsers with the same user logged in use the computerroom module because the "pid" field of a lot of requests are changed to the module process pid of the executing session. If this session dies the room info/status file contains the wrong PID. But I currently see no big impact and it's not easy to fix.
I started an exam and saw this traceback in the developer console when opening the room and the room selection did not continue: dojo.js.uncompressed.js:81314 TypeError: Cannot read property 'finishExam' of null(…) "TypeError: Cannot read property 'finishExam' of null at _updateHeader (http://10.200.27.118/univention-management-console/js_$20160712184347$/umc/modules/computerroom.js:575:25) at renderSearchPage (http://10.200.27.118/univention-management-console/js_$20160712184347$/umc/modules/computerroom.js:620:9) at _renderPages (http://10.200.27.118/univention-management-console/js_$20160712184347$/umc/modules/computerroom.js:493:9) at http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:819:75 at e (http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:766:337) at h (http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:766:263) at f.resolve (http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:768:352) at http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:1949:111 at e (http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:766:337) at h (http://10.200.27.118/univention-management-console/js_$20160712184347$/dojo/dojo.js:766:263)
I could not reproduce the error but with the traceback I am able to prevent it :) Also another null pointer exception has been fixed which was caused when selecting a room. ucs-school-umc-computerroom (8.0.14-2): r75114 | Bug #40901: fix race conditions and null pointer exceptions
OK: problems 1 and 2 were solved OK: manual test: When logged in with different teacher accounts in separate browsers, it is not possible to take over a room with a running exam, to changes its settings or to start a second exam in the same room. OK: manual test: If a room was already open and in a second window an exam was started, the first window was updated to show the running exam. OK: advisories
This test failed on 2 systems. http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204.1%20(R2)%20Multiserver/329/SambaVersion=s4-school-only/testReport/90_ucsschool/22_computerroom_module_settings/test/ http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204.1%20(R2)%20Multiserver/329/SambaVersion=s4-all-components/testReport/90_ucsschool/22_computerroom_module_settings/test/ In both cases the shareMode did not switch from "all" to "home". Please check, if this is related to this bug.
Another javascript traceback, because I didn't gave a function but a function call to deferred.then(): TypeError: func is not a function(…) "TypeError: func is not a function at signalListener (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37582:21) at signalWaiting (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37573:4) at Deferred.resolve (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37737:5) at http://10.200.27.118/univention-management-console/js_$20160812164716$/umc/modules/computerroom.js:984:15 at stop (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:40157:5) at .<anonymous> (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:40136:11) at http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:40554:55 at signalListener (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37582:21) at signalWaiting (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37573:4) at Deferred.resolve (http://10.200.27.118/univention-management-console/js_$20160812164716$/dojo/dojo.js.uncompressed.js:37737:5) ---------------------------------------- This causes that in case of errors when finishing an exam no error message is shown.
(In reply to Sönke Schwardt-Krummrich from comment #10) > This test failed on 2 systems. > > http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204. > 1%20(R2)%20Multiserver/329/SambaVersion=s4-school-only/testReport/ > 90_ucsschool/22_computerroom_module_settings/test/ > > http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204. > 1%20(R2)%20Multiserver/329/SambaVersion=s4-all-components/testReport/ > 90_ucsschool/22_computerroom_module_settings/test/ > > In both cases the shareMode did not switch from "all" to "home". > > Please check, if this is related to this bug. I cannot really reproduce this: root@xen8:~# curl 'http://Administrator:univention@localhost/univention-management-console/command/computerroom/room/acquire' -H 'Content-Type: application/json' -d '{"options":{"room":"cn=oldschool-raum1,cn=raeume,cn=groups,ou=oldschool,dc=school,dc=local"}}' ; echo; {"status": 200, "message": null, "result": {"info": {"examEndTime": null, "exam": null, "examDescription": null, "user": "uid=Administrator,cn=users,dc=school,dc=local", "room": "cn=oldschool-raum1,cn=raeume,cn=groups,ou=oldschool,dc=school,dc=local"}, "message": "OK", "success": true}} root@xen8:~# curl 'http://Administrator:univention@localhost/univention-management-console/command/computerroom/settings/get' ; echo; {"status": 200, "message": null, "result": {"printMode": "default", "shareMode": "all", "period": "13:15:00", "customRule": "", "internetRule": "none"}} root@xen8:~# date Fr 9. Dez 12:32:33 CET 2016 root@xen8:~# curl 'http://Administrator:univention@localhost/univention-management-console/command/computerroom/settings/set' -H 'Content-Type: application/json' -d '{"options":{"customRule": "univention.de", "printMode": "default", "internetRule": "none", "shareMode": "home", "period": "12:34"}}' {"status": 200, "message": null, "result": null} root@xen8:~# atq 6 Fri Dec 9 12:34:00 2016 a root root@xen8:~# date Fr 9. Dez 12:33:51 CET 2016 root@xen8:~# curl 'http://Administrator:univention@localhost/univention-management-console/command/computerroom/settings/get' ; echo; {"status": 200, "message": null, "result": {"printMode": "default", "shareMode": "home", "period": "13:15:00", "customRule": "", "internetRule": "none"}} root@xen8:~# date Fr 9. Dez 12:34:43 CET 2016 root@xen8:~# curl 'http://Administrator:univention@localhost/univention-management-console/command/computerroom/settings/get' ; echo; {"status": 200, "message": null, "result": {"printMode": "default", "shareMode": "all", "period": "13:15:00", "customRule": "", "internetRule": "none"}}
(In reply to Sönke Schwardt-Krummrich from comment #10) > This test failed on 2 systems. > > http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204. > 1%20(R2)%20Multiserver/329/SambaVersion=s4-school-only/testReport/ > 90_ucsschool/22_computerroom_module_settings/test/ > > http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204. > 1%20(R2)%20Multiserver/329/SambaVersion=s4-all-components/testReport/ > 90_ucsschool/22_computerroom_module_settings/test/ > > In both cases the shareMode did not switch from "all" to "home". > > Please check, if this is related to this bug. Nice, look at this: From univention-management-console-computerroom.log: 08.12.16 22:27:43.204 MODULE ( INFO ) : Endtime: 22:30:00 08.12.16 22:27:43.204 MODULE ( INFO ) : Remove settings at 2016-12-08 22:30:43.204131 The atjob for removing the settings will be called at 22:30:43 ! The seconds are not reset to 00. The test case checks for the settings at 22:30:08 seconds: [2016-12-08 22:30:08.885185] ### FAIL ### [2016-12-08 22:30:08.885200] Current settings ({u'customRule': u'', u'printMode': u'default', u'internetRule': u'none', u'shareMode': u'all', u'period': u'23:30:08.882137'}) do not match expected ones ({'customRule': u'', 'printMode': 'default', 'internetRule': 'none', 'shareMode': 'home', 'period': u'23:30:08.882137'}) I will fix this in this bug :)
ucs-school-umc-computerroom (8.0.15-1): r75152 | Bug #40901: execute at jobs to reset settings at second 0
OK: code change OK: functional test OK: advisory
UCS@school 4.1 R2 v9 has been released. http://docs.software-univention.de/changelog-ucsschool-4.1R2v9-de.html
*** Bug 41278 has been marked as a duplicate of this bug. ***