#3709 [RFE] Set default attribute values for migrate-ds command
Opened 10 years ago by mkosek. Modified 7 years ago

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 967865

Please note that this Bug is private and may not be accessible as it contains
confidential Red Hat customer information.

Entries that are being migrated may not contain all attributes that FreeIPA
schema has as MUST (e.g. sn attribute).

Add a new option to migrate-ds command where user could define (attribute, value)
pairs which would be used as a default when the attribute is not present in the
source entry. We will want to define this pairs for user/group entries separately.

Example:

$ ipa migrate-ds $MIGRATION_URI --user-default-attribute=sn=undefined \
  --user-default-attribute=mail=noreply@company.test

I do not think I was clear. The pairs will be attribute name=attribute name. Not the value.
This would allow to use contents of another attribute that hopefully exists as a source of the value.

for example is there are missing SNs in your deployment you can say:

$ ipa migrate-ds $MIGRATION_URI --user-default-attribute=sn=mail \
--user-default-attribute=cn=uid

Then if SN is not defined in the entry it code will first look if mail attribute is defined for this entry. If it is, the value of the mail attribute would be used as value of SN, otherwise an error would be returned as it is now.

Right, this approach makes sense too. Though I still think that somebody may want to use the originally proposed approach to set a fixed value instead of other attribute's value.

What about combining both approaches to one general approach using Python's native Templating features?

We could easily accept both:

$ ipa migrate-ds $MIGRATION_URI --user-default-attribute='sn=$cn'

or

$ ipa migrate-ds $MIGRATION_URI --user-default-attribute='sn=undefined'

Replying to [comment:3 mkosek]:

What about combining both approaches...

Makes sense

3.4 development was shifted by one month, moving tickets to reflect reality better.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Moving unfinished November tickets to January.

Metadata Update from @mkosek:
- Issue assigned to someone
- Issue set to the milestone: Future Releases

7 years ago

Login to comment on this ticket.

Metadata