Bug 50080

Summary:	Handle name conflicts between extended attributes and existing UDM property
Product:	UCS	Reporter:	Arvid Requate <requate>
Component:	UDM - Extended Attributes	Assignee:	UMC maintainers <umc-maintainers>
Status:	NEW ---	QA Contact:	UMC maintainers <umc-maintainers>
Severity:	normal
Priority:	P5	CC:	best, bremer
Version:	UCS 4.4
Target Milestone:	---
Hardware:	Other
OS:	Linux
What kind of report is it?:	Development Internal	What type of bug is this?:	---
Who will be affected by this bug?:	---	How will those affected feel about the bug?:	---
User Pain:		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:
Bug Depends on:
Bug Blocks:	50081, 50033
Attachments:	Some starting point

Description Arvid Requate

2019-08-29 10:54:05 CEST

At the example of Bug 50033 we found out, that it's hard to add properties to UDM  in an errata update, because a customer could have defined an extended attibute that conflicts with the UDM property.

I see three cases, I'll explain at the example of an property "initials", which should be mapped to the  LDAP-attribute "initials":


Case 1) Extended Attribute does exactly the same, mapping the LDAP attribute "initials" to the UDM property of the same name

Case 2) Extended Attribute maps the LDAP-Attribute "initials" to the UDM property  with a different name (e.g. "myInitials")

Case 3) Extended Attribute maps the UDM property "initials" to an LDAP attribute with a different name (e.g. "univentionFreeAttribute7")


My impression is that it should be technically possible to handle this in a better way that doesn't result in undefined behaviour that causes trouble e.g. for The S4-Connector.

Comment 1 Florian Best

2019-08-29 11:03:04 CEST

Created attachment 10168 [details]
Some starting point