Bug 50031 - Allow user import via UMC with school and role gathered from import data
Allow user import via UMC with school and role gathered from import data
Status: NEW
Product: UCS@school
Classification: Unclassified
Component: UMC - User Import UI
UCS@school 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS@school maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-20 13:36 CEST by Valentin Heidelberger
Modified: 2023-10-26 14:39 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very 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?:
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 Valentin Heidelberger univentionstaff 2019-08-20 13:36:05 CEST
The user import module requires the user to select a school and role for the users they're about to submit import data for. 
A customer wants to get this information from the import data without the importing user having to specify it.

Maybe we could change the module as follows:
- Two new UCR vars to deactivate the school/role selection in the UMC module
- If the var is set the module just uses the mapping defined in the import configs
- If there is no mapping for school or role the import fails

It would be nice if this was possible especially because the import can do this technically but only via the CLI afaik.
Comment 1 Daniel Tröder univentionstaff 2019-08-21 09:05:03 CEST
The user that wants to start an import must be in an import-group that allows the school+role selection.

Without this limitation a teacher from SchoolA can delete users from SchoolB.

It was a conscious design decision to keep the permission checks in the Import-HTTP-API (aka Newton API) instead of having it in the import framework.
The permissions apply to the "schools" property, and thus also to the "school_classes" property.

There are two possibilities to implement this:

1) check permissions in the import framework when creating/modifying/moving/deleting users
2) check permissions in the Newton API by parsing the CSV file

The latter is less secure, because it wouldn't detect the transfer of users from a prohibited OU into one of the allowed OUs.

The problem: currently the "source_uid" is calculated as "$OU-$ROLE". Thus existing members of other OUs cannot be modified, moved or deleted because they are simply not part of the set of user objects of that source_uid.
When the source_uid cannot be used anymore as a limiting factor for the import, searches for users using the record_uid can reveal users of other OUs.

So it really has to be done in the import framework (option 1): The permissions have to be available in the import and in all operations (create/modify/move/delete) the properties "school", "schools" and "school_classes" have to be checked.