Bug 49781 – allow additional LDAP attributes in appcenter IDM notifications (Push)

Bug 49781 - allow additional LDAP attributes in appcenter IDM notifications (Push)


Summary:	allow additional LDAP attributes in appcenter IDM notifications (Push)

Status:	NEW

Product:	UCS
Classification:	Unclassified
Component:	App Center
Version:	UCS 4.4
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	App Center maintainers
QA Contact:	App Center maintainers

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2019-07-03 09:26 CEST by Daniel Tröder
Modified:	2019-07-22 13:46 CEST (History)
CC List:	5 users (show)

See Also:
What kind of report is it?:	Bug Report
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
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Daniel Tröder

2019-07-03 09:26:16 CEST

An application may want to react to an LDAP attribute that does not have a mapping to a UDM property (e.g. krb5Key). Currently that's not possible, because the appservers dump of the "new" dictionary contains only UDM-mapped attributes.

Allow the configuration of a list of LDAP attribute names. If those keys are present in the "new" dictionary of the listener module, append them (and their value) to the "object" dictionary of the generated JSON file.

Comment 2 Florian Best

2019-07-03 09:33:49 CEST

Wouldn't it be better to not mix it into 'object' but create a new dict 'attrs'?

Comment 3 Felix Botner

2019-07-22 12:26:30 CEST

(In reply to Florian Best from comment #2)
> Wouldn't it be better to not mix it into 'object' but create a new dict
> 'attrs'?

yes, +

Comment 4 Daniel Tröder

2019-07-22 13:46:12 CEST

I understand this won't happen, because it's against the intended design. Users should use extended attributes, when they need it. My use case (reading krb5Key) is to special, to mess up the design.
If you wish (from my point of view) you can close it with wontfix.