Bug 54521 - ERROR Getting ... UDM object: No DN!
ERROR Getting ... UDM object: No DN!
Status: NEW
Product: UCS@school
Classification: Unclassified
Component: kelvin-rest-api-client
unspecified
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS@school maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-03-08 14:30 CET by Jürn Brodersen
Modified: 2022-07-04 11:55 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 1: Cosmetic issue or missing function but workaround exists
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.023
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): bitesize
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jürn Brodersen univentionstaff 2022-03-08 14:30:50 CET
Creating a user without an explicit username logs an error. It seems that error can (and must be) ignored. This is confusing. I think we should lower the log level.

The error is logged by ucs-school-lib/modules/ucsschool/lib/models/base.py::get_udm_object and the function returns None as a fallback.
That function is later used to check for existence of the user object: `self.get_udm_object(lo) is not None`

This can be reproduced running the test: `tests/test_route_user.py::test_create_without_username` and checking the log file `/var/log/univention/ucsschool-kelvin-rest-api/http.log` for the following errors:
ERROR Getting ImportTeacher UDM object: No DN!
ERROR Getting ImportStudent UDM object: No DN!
ERROR Getting ImportStaff UDM object: No DN!
ERROR Getting ImportTeachersAndStaff UDM object: No DN!

Note:
This seems to be a more general school lib problem, but I only saw it in combination with kelvin. I might just have missed it in our tests or we just don't test it?
Comment 2 Daniel Tröder univentionstaff 2022-07-04 11:53:39 CEST
Hm... bad logging creates problems...
And returning different types (UDM object and None) is also not good...
Maybe get_udm_object() can throw an exception instead of returning None, which the callers can catch and log according to the context: ERROR if it indeed was an error or nothing/debug if it was an expected test result.