Univention Bugzilla – Bug 56702
Removal of class assignments during csv import
Last modified: 2023-10-05 14:23:52 CEST
UCS: 5.0-4 errata779 Installed: ucsschool=5.0 v4 4.4 It is possible for both teachers and students to include class groups in the import. However, this option is not available in all schools. This is because the assignment of teachers to classes is not maintained everywhere in the school administration software. Thus, there are schools that assign classes via the user import, and schools that traditionally assign teachers to classes manually via the management console. So far so good, but unfortunately this leads to a problem when a teacher works at multiple schools and one of them passes on class assignments and the other does not. The person in the import file then looks like this (irrelevant attributes omitted) (RecordUid;LastName;FirstName;Schools;Classes) 12345;"Mustermann";"Max";"445,504";"445-Q2A,445-Q2B,445-Q2C,445-Q2D";; (For the sake of completeness: In our import config for teachers, "school_classes_keep_if_empty" is set to true, so that for teachers without class assignments, the existing classes set via UMC are not used. classes set via UMC will not be touched). Here, Max Mustermann teaches at schools 445 and 504, but only 445 has classes. Because classes are specified, the import process interprets them as global target state - so exactly these classes are set for the person, and other class memberships, even at other schools, are removed. This way, if the import is running every night, it is impossible to manually assign this person to classes in school 504 via the Management Console. So my request would be to differentiate between the individual schools when setting or not setting class groups. So at school 445 should be exactly the listed classes and at school 504 the existing class assignments should not be touched, because there are no classes listed here. Technically this should not be a problem, because the importer knows exactly which class group belongs to which school. Unfortunately, this is not just a minor inconvenience, as it limits the ability of affected teachers to use school IT. Examples: - on the iPads, class assignments from teachers are mandatory to use the classroom features - All services connected to ID Broker (e.g. Bettermarks, Sofatutor) cannot be used because they require teachers to assign classes. And teachers cannot even help themselves with manually created workgroups, because ID Broker still does not take these groups into account.
For completeness my previous remarks on that in writing: The import is designed to be declarative. This means that you do not write into the file what it should do (e.g. "Assign teacher1 to class1"), but you describe the final state you want to see ("Teacher1 is part of class1"), how the state is reached is up to the importer. In the concrete example that's what happens: A state is described ("Teacher is part of school1 and school2, as well as school1-class1 and school1-class2") and exactly this state is created - by removing the in this case desired assignments. So the importer basically works as it should, but for this feature it lacks (another) special handling like the described "school_classes_keep_if_empty". I understand why this is a pain for the customer, but it will take some time until we have a balanced solution: We are breaking the paradigm of describing the target state to the importer, because the whole state is not described. In other words: How should the importer know which classes of which schools he is allowed to remove and which not? In case of doubt, this must all be solved via additional (complicated) configuration.