Univention Bugzilla – Bug 52424
No error raised when Workgroup existed, but SchoolClass was required
Last modified: 2020-11-25 09:45:53 CET
It would be nice, if the error message of even some imports are more understandable. I came across this traceback: 2020-11-23 10:56:03 DEBUG base.get_only_udm_obj:1039 Getting SchoolClass UDM object by filter: name=sun-4b 2020-11-23 10:56:03 ERROR mass_import.import_users:131 cn=sun-4b,cn=klassen,cn=schueler,cn=groups,ou=sun,dc=portal,dc=schein,dc=me Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/ucsschool/importer/mass_import/mass_import.py", line 123, in import_users user_import.create_and_modify_users(imported_users) # 90% - 100% File "/usr/lib/pymodules/python2.7/ucsschool/importer/mass_import/user_import.py", line 206, in create_and_modify_users success = user.create(lo=self.connection) File "/usr/lib/pymodules/python2.7/ucsschool/importer/models/import_user.py", line 381, in create res = super(ImportUser, self).create(lo, validate) File "/usr/lib/pymodules/python2.7/ucsschool/lib/models/base.py", line 501, in create success = self.create_without_hooks(lo, validate) File "/usr/lib/pymodules/python2.7/ucsschool/lib/models/base.py", line 531, in create_without_hooks self.do_create(udm_obj, lo) File "/usr/lib/pymodules/python2.7/ucsschool/lib/models/user.py", line 290, in do_create success = super(User, self).do_create(udm_obj, lo) File "/usr/lib/pymodules/python2.7/ucsschool/lib/models/base.py", line 555, in do_create udm_obj.create() File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 557, in create dn = self._create(response=response, serverctrls=serverctrls) File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 1270, in _create six.reraise(exc[0], exc[1], exc[2]) File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 1256, in _create self._ldap_post_create() File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/users/user.py", line 1641, in _ldap_post_create self.__update_groups() File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/users/user.py", line 1518, in __update_groups grpobj = group_mod.object(None, self.lo, self.position, group) File "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", line 232, in __init__ raise univention.admin.uexceptions.noObject(self.dn) noObject: cn=sun-4b,cn=klassen,cn=schueler,cn=groups,ou=sun,dc=portal,dc=schein,dc=me 2020-11-23 10:56:03 INFO user_import.log_stats:695 ------ User import statistics ------ Unfortunately a teacher already created a workgroup with the name of the class that should be imported now. The message "noObject" is very confusing. You will not find a class with this name but a workgroup. The customer cannot help himself or understand, what went wrong. Finding out was very "expensive" for the customer and support. Even it is simple.
Maybe as addition, the customer cannot import his students until this problem was solved. This took some time. That is why I choose "Blocking".
(In reply to Christina Scheinig from comment #0) > It would be nice, if the error message of even some imports are more > understandable. > I came across this traceback: [..] > "/usr/lib/python2.7/dist-packages/univention/admin/handlers/__init__.py", > line 232, in __init__ > raise univention.admin.uexceptions.noObject(self.dn) > noObject: > cn=sun-4b,cn=klassen,cn=schueler,cn=groups,ou=sun,dc=portal,dc=schein,dc=me > 2020-11-23 10:56:03 INFO user_import.log_stats:695 ------ User import > statistics ------ > > Unfortunately a teacher already created a workgroup with the name of the > class that should be imported now. > > The message "noObject" is very confusing. You will not find a class with > this name but a workgroup. The customer cannot help himself or understand, > what went wrong. > Finding out was very "expensive" for the customer and support. Even it is > simple. The error message is correct: no object exists with the DN cn=sun-4b,cn=klassen,cn=schueler,... IMHO there is nothing confusing about the error message. An LDAP search or UMC-group search for "sun-4b" would have shown the Workgroup instead of the SchoolClass. Workgroups are not supported by the UCS@school import. Anyway: During the import there should have been an _earlier_ error, about not being able to create a SchooClass with that name. That error message would also have helped to understand the problem much faster. (In reply to Christina Scheinig from comment #1) > Maybe as addition, the customer cannot import his students until this > problem was solved. This took some time. That is why I choose "Blocking". It's not an error in the product - it was an user error. I have changed the priority to reflects that this is only about making it easier to find a problem in a customer system. Task: When creating users, the ucsschool.lib creates the SchoolClasses that the user should be in. When checking for the existence of those groups, make sure they are SchoolClass objects.
I do not have seen an earlier error message. I can provide the logfile and you have a look for yourself. This was the first occurance. How should I or the customer know, that "workgroups are not supported by the UCS@school import". A teacher created that workgroup and the administrator does the import. We saw (both of us in support) that the workgroup exists, but not knowing, that this is the cause of the aborted import. The expectation was, that this would be shown as the error message or as the cause of the problem in any way.
(In reply to Christina Scheinig from comment #3) > The expectation was, that this would be shown as the error message or as the > cause of the problem in any way. Yes, that is what this bug is about now (see "Task" in comment above).