Bug 41620 - behavior when changing school → don't add classes at other school
behavior when changing school → don't add classes at other school
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: Ucsschool-lib
UCS@school 4.1 R2
Other Linux
: P5 normal (vote)
: UCS@school 4.1 R2 vXXX
Assigned To: Florian Best
Daniel Tröder
:
Depends on: 40870
Blocks: 41349
  Show dependency treegraph
 
Reported: 2016-06-21 10:47 CEST by Florian Best
Modified: 2016-10-06 08:55 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.171
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2016-06-21 10:47:02 CEST
The new functionality to support a school change puts the user into the same classes of the other school (and creates the classes if necessary).

I think this behavior is not good - makes no sense in practice/real life.
Let's remove this.

+++ This bug was initially created as a clone of Bug #40870 +++

The ucs-school-lib does not support school changes for users. This is currently deactivated/ignored within the code and needs to be implemented for customer projects and UCS@school 4.1R2.
Comment 1 Florian Best univentionstaff 2016-06-21 11:04:00 CEST
ucs-school-lib (9.0.20-4):
r70462 | Bug #41620: don't put user into same school classes afer school move

ucs-school-lib.yaml:
r70462 | Bug #41620: don't put user into same school classes afer school move
Comment 2 Daniel Tröder univentionstaff 2016-06-21 11:54:24 CEST
OK: Code change
OK: manual test:

users1 = User.get_all(lo, "schule1")
print "users schule1:", users1
users2 = User.get_all(lo, "schule2")
print "users schule2:", users2
print "classes of users in schule1:", [(user.name, user.school_classes) for user in users1]
print "classes of users in schule2:", [(user.name, user.school_classes) for user in users2]

→ users schule1: [Student(name='anton1', school='schule1', dn='uid=anton1,cn=schueler,cn=users,ou=schule1,dc=uni,dc=dtr')]
→ users schule2: []
→ classes of users in schule1: [('anton1', {'schule1': ['schule1-1A']})]
→ classes of users in schule2: []

print "all classes of schule1:", SchoolClass.get_all(lo, "schule1")
print "all classes of schule2:", SchoolClass.get_all(lo, "schule2")

→ schule1: [SchoolClass(name='schule1-1A', school='schule1', dn='cn=schule1-1A,cn=klassen,cn=schueler,cn=groups,ou=schule1,dc=uni,dc=dtr')]
→ schule2: []

anton1 = Student.from_dn("uid=anton1,cn=schueler,cn=users,ou=schule1,dc=uni,dc=dtr", "schule1", lo)
anton1.change_school("schule2", lo)
→ True

users1 = User.get_all(lo, "schule1")
print "users schule1:", users1
users2 = User.get_all(lo, "schule2")
print "users schule2:", users2
print "classes of users in schule1:", [(user.name, user.school_classes) for user in users1]
print "classes of users in schule2:", [(user.name, user.school_classes) for user in users2]
print "all classes of schule1:", SchoolClass.get_all(lo, "schule1")
print "all classes of schule2:", SchoolClass.get_all(lo, "schule2")

→ users schule1: []
→ users schule2: [Student(name='anton1', school='schule2', dn='uid=anton1,cn=schueler,cn=users,ou=schule2,dc=uni,dc=dtr')]
→ classes of users in schule1: []
→ classes of users in schule2: [('anton1', {})]
→ all classes of schule1: [SchoolClass(name='schule1-1A', school='schule1', dn='cn=schule1-1A,cn=klassen,cn=schueler,cn=groups,ou=schule1,dc=uni,dc=dtr')]
→ all classes of schule2: []
                         ^^^^
OK: anton1s old classes from his old school were not created at the new school
Comment 3 Daniel Tröder univentionstaff 2016-06-21 16:05:29 CEST
The test 90_ucsschool/80_move_users_into_another_ou was modified in r70499 to test this.

It does reveal, that if in the new school a class with the same name exists as in the old school, the user will be added to it. A non-existing class will however not be created. So regarding _this_ bug, all is fine. But if that behavior is not intended, please create a new bug (don't reopen).

The current version of 90_ucsschool/80_move_users_into_another_ou assumes it is intended behavior. If a new bug is created to change it, please also adapt the test.
Comment 4 Daniel Tröder univentionstaff 2016-06-21 17:17:34 CEST
(In reply to Daniel Tröder from comment #3)
> The test 90_ucsschool/80_move_users_into_another_ou was modified in r70499
> to test this.
> 
> It does reveal, that if in the new school a class with the same name exists
> as in the old school, the user will be added to it. A non-existing class
> will however not be created. So regarding _this_ bug, all is fine. But if
> that behavior is not intended, please create a new bug (don't reopen).
> 
> The current version of 90_ucsschool/80_move_users_into_another_ou assumes it
> is intended behavior. If a new bug is created to change it, please also
> adapt the test.
Ignore this. The test was bugged. It was adding users to school Bs class before the move. Fixed in 3.0.12-12
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2016-10-04 13:24:50 CEST
UCS@school 4.1 R2 v5 has been released.

http://docs.software-univention.de/changelog-ucsschool-4.1R2v5-de.html

If this error occurs again, please clone this bug.