Comment 1 Lukas Oyen 2017-08-21 10:20:04 CEST

I can imagine three cases where extensibility is useful:

1) The customer wants to add a new mapping group, like 'user', 'dc' or
  'windowscomputer'.
2) The customer wants to add new attributes to an existing mapping group.
3) The customer wants to perform complex changes, like removing, adding or
  changing existing groups/attributes, including various variables of a property
  like `scope` or `ignore_subtree`.

Two ideas for some extensiblily come to mind:

a) The declarative approach: files in /etc/univention/s4/mapping.d/ that allow
  for extensions and simple changes via some overwriting/inheritance scheme.
  Those files could define an `s4_mapping` dictionary that gets merged into the
  current one, adding new mapping groups or overwriting variables of the
  properties. This needs some thought as the customer may want to extend
  `attributes` and not simply overwrite it.

3) The functional approach: The user can supply a function that gets executed
  with the `s4_mapping` as an argument and performs transformations. We could
  supply a simple library for common operations and a guide on how to keep those
  transformations readable.

Approach a) would be easier to understand but is also limited in its
capabilities. Approach b) can lead to unreadable code, but supports all kinds of
transformations.

In either case, we should supply a simple command line tool, that performs the
merging/transformations and outputs the final `s4_mapping` for debugability.

Comment 2 Felix Botner 2017-10-26 12:28:38 CEST

a) sounds good

 * our mapping goes to /usr/share/pyshared/univention/connector/

 * by default the connector uses this mapping

 * except there is a file /etc/univention/connector/ad/custom_mapping.py,
   which then is used a source for the mapping definition

 * the custom_mapping can just import our mapping and make the desired changes

import univention.connector.ad.mapping as mapping

print mapping.ad_mapping

mapping.ad_mapping['user'].post_attributes['newAttr'] =  univention.connector.attribute(
        ucs_attribute='newAttr',
        ldap_attribute='newAttr',
        con_attribute='newAttr',
)

del mapping.ad_mapping['user'].post_attributes['organisation']


return mapping.global_ignore_subtree, mapping.ad_mapping

 * the resulting mapping is always written to /var/run/connector/mapping
   and the connector uses this file 

 * after the update with an old /etc/univention/connector/ad/mapping, the 
   connector refuses to start until the old mapping
   /etc/univention/connecto/ad/mapping is removed (converted to 
   /etc/univention/connector/ad/custom_mapping.py)

 * additionally we should think about some versioning, maybe a "API" version
   in our mapping. The custom mapping has to set the same version and if
   they no longer match, the connector refuses to start or give some kind of 
   warning ....

Comment 3 Stefan Gohmann 2017-12-19 09:27:51 CET

It was not part of the voting process, so removing the target milestone.

Comment 4 Florian Best 2019-10-23 13:20:34 CEST

*** This bug has been marked as a duplicate of bug 48410 ***