MID-8802 Added displayName and preferredName to UserType by kay1313 · Pull Request #621 · Evolveum/midpoint

kay1313 · 2026-04-23T10:13:12Z

Summary

This PR introduces UserType.displayName and preferredName, and updates selected presentation paths to use displayName instead of fullName.

The goal is to separate:

fullName → legal/full name
preferredName → user-preferred visible name
displayName → computed, stored effective display name used in UI/notifications

Core behavior

displayName is now model-maintained:

displayName = preferredName (if non-empty)
           else fullName
           else null

Implemented in projector (AssignmentHolderProcessor)
Stored in repository and queryable
Consumers can rely on getDisplayName() without fallback logic

Scope of changes

1. Schema & Repository

Added preferredName and displayName to UserType
Extended Sqale/native repo mappings and query support

2. Model

Introduced projector logic to compute and persist displayName
Generates secondary deltas when needed

3. Presentation (GUI)
Switched selected user-facing labels from fullName → displayName:

user summary/header
sidebar current user
access request labels
delegation UI
certification / assignment UI
merge details
generic object labels (via utilities)

4. Search / Reporting
Added displayName to:

searchable user fields
default/available user list columns
built-in user report export

5. Notifications

Notification formatting now uses displayName for user labels
Covers requestor/requestee and reference-based display helpers

What was intentionally NOT changed

fullName semantics (remains legal/full name)
identity-related logic (OID, name, DN/CN, matching)
debug/repository DTOs (keep raw stored values)
broad generic helpers with cross-cutting impact

This is a targeted presentation-layer shift, not a global rename.

Notes / impact

Existing users need recompute to populate displayName
Some tests were adjusted due to new computed/stored field behavior

Detailed Impact (by area)

Area	File(s)	Change	Why
GUI utilities	WebComponentUtil.java	Use displayName	Centralize user label semantics
Search	SearchBoxConfigurationBuilder.java, SearchableItemsDefinitions.java	Add displayName	Make new visible name searchable
Access UI	AccessRequestMixin.java	Use displayName	Show preferred name in requests
Delegation	DelegationEditorPanel.java	Use displayName	Align delegation labels with UI naming
User tables	ColumnUtils.java, DefaultColumnUtils.java	Add column	Expose displayName in lists
Sidebar	SideBarMenuPanel.java	Use displayName	Show correct current user label
Summary	UserSummaryPanel.java	Use displayName	Replace header label
Certification	CertCampaignDto.java, DirectAssignmentCertGuiHandler.java	Use displayName	Consistent user labeling
Merge UI	MergeObjectDetailsPanel.java	Use displayName	Show effective name
Selection UI	PageAttorneySelection.java	Add column	Show both names
Core util	ObjectTypeUtil.java	Update	Align helper behavior
Model	AssignmentHolderProcessor.java, Components.java	Compute displayName	Core logic
Visualization	Visualizer.java	Use displayName	UI consistency
Notifications	BaseEventImpl.java, ValueFormatter.java, etc.	Use displayName	Notification text
Repo	SqaleUtils.java, MUser.java, QUser.java, QUserMapping.java	Persist fields	Storage + query
Ninja	export classes	Adjust fields	Keep export consistent

Result

displayName becomes the single source of truth for visible user name
UI/notifications are aligned with user-preferred naming
fallback logic is centralized in model instead of duplicated across code

1azyman

Release notes need a bit better description, mainly in:
** Upgrade From MidPoint 4.9 (to be renamed to 4.10), removed content that's not relevant for upgrade 4.10->4.11.
** Changes In Initial Objects Since 4.10, again remove content that's not relevant
Initial object template for person (380-something.xml) is missing display name mapping, which will take value from preferredName (if it has value) or from fullName.
I see few replacements in GUI from fullName -> displayName.
Customers will not have users with displayName populated right after upgrade, wouldn't it be better to use WebComponentUtil.getDisplayNameOrName() or something similar new that will return something more gracefully like displayName/fullName/name (in this order)?
Or more probably in ObjectTypeUtil.getDisplayName(ObjectType) return displayName or fullName...
I'm not sure, just to make it less painful for customers. I was looking at SidebarMenuItemPanel, UserSummaryPanel, AccessRequestMixin. Something that later can be "switched of" and to use only displayName in next versions.
I think this graceful handling is not relevant for reports and backend code.
More notes will be added as didn't have time to go through all the code yet.

1azyman · 2026-04-29T20:59:22Z

                <previousColumn>activationColumn</previousColumn>
            </column>
-            <column id="10">
+            <column id="11">


Please revert container ids changes and only create new id for new container (display name column). They don't have to be ordered. If we leave it shifted like this, diff during upgrade will display more "fake" changes since container with id=8 is now different then in previous version. If just displayName(id=12) is added, only that one will be picked up when object is used during diff operation. There's also "natural keys" for some containers defined, but it's not everywhere, so we want to stay on safe side.

1azyman · 2026-06-16T20:22:17Z

    WHERE connectorHostRefTargetOid IS NOT NULL;
 $aa$);

+call apply_change(58, $aa$


Don't forget to add annotations for schema generator :)

1azyman · 2026-06-16T20:30:03Z

                        partialProcessingOptions::getFocusCredentials,
                        Projector.class, context, now, task, result);

+                // Maintain UserType.displayName (computed from preferredName/fullName)


This must not be here. This is done via configuration, by default in person object template (initial objects). Customer can put in whatever is needed, not necessarily values from preferred/full name.

1azyman · 2026-06-16T20:31:26Z

        LensUtil.checkContextSanity(context, "focus processing");
    }

+    @ProcessorMethod


same as above. this is not a correct approach. "Maintaining" state of attribute (any and all) is done via mappings placed in different configuration objects in customer deployment.

1azyman · 2026-06-16T20:32:21Z

    public static final String FOCUS_LIFECYCLE = "focusLifecycle";
    public static final String OBJECT_TEMPLATE_AFTER_ASSIGNMENTS = "objectTemplateAfterAssignments";
    public static final String FOCUS_CREDENTIALS = "focusCredentials";
+    public static final String FOCUS_DISPLAY_NAME = "focusDisplayName";


Obsolete, see AssignmentHolderProcessor comments

1azyman · 2026-06-16T20:42:29Z

        if (focusDelta.findItemDelta(FocusType.F_ITERATION_TOKEN) != null) {
            expectedModifications++;
        }
+        if (focusDelta.findItemDelta(UserType.F_DISPLAY_NAME) != null) {


This probably should not be here?I'd expect it's related to that assignment holder processor stuff?

1azyman · 2026-06-16T20:42:45Z

        if (focusDelta.findItemDelta(FocusType.F_ITERATION_TOKEN) != null) {
            expectedModifications++;
        }
+        if (focusDelta.findItemDelta(UserType.F_DISPLAY_NAME) != null) {


Same as above?

1azyman · 2026-06-16T20:51:45Z

        String oid = focusContext.getOid();

-        String fullName = emptyIfNull(getFullName(focus));
+        String displayName = emptyIfNull(getDisplayName(focus));


As mentioned in previous review/comments. Wouldn't it be more "safe" it there's some Util method used all over the midpoint code for similar scenarios. Previously it obtained full name from UserType/prism object. now it would first try to obtain displayName and if that's null let's get fullName and if not then null? and we can get rid of that a bit later - and best part would be, changed would happend only in one place. This displayName->fullName->null can't probably be used everywhere but on many places it would make sense (simplify admin life by displaying most meaningful presentation of UserType). what do you think?

Remove hardcoded displayName maintenance from the projector and configure it through the person object template, using preferredName with fullName fallback. Add coverage for person and non-person users. Add display-name fallback in GUI and notifications for users without displayName. Preserve report column ids while adding the displayName column, and update release notes.

kay1313 · 2026-06-18T10:33:32Z

Added the person-template displayName mapping with preferredName/fullName fallback.
Added the common display-name fallback and updated the relevant usages.
Kept existing report column ids unchanged and added displayName as a new column.
Added annotations for sql changes.
Removed the hardcoded projector maintenance and related obsolete expectations.
Added focused coverage for person and non-person users.
Updated to use the common display-name helper.

1azyman self-requested a review April 29, 2026 20:35

1azyman requested changes Apr 29, 2026

View reviewed changes

1azyman requested changes Jun 16, 2026

View reviewed changes

kay1313 force-pushed the improvement/MID-8802 branch from 08a77b2 to bbe2813 Compare June 17, 2026 11:33

kay1313 added 2 commits June 18, 2026 12:00

MID-8802 Added displayName and preferredName to UserType

5c1cbb9

MID-8802 Release notes and tests updates

49e9b0a

kay1313 force-pushed the improvement/MID-8802 branch 3 times, most recently from 3ccb129 to fbc0d61 Compare June 18, 2026 10:23

kay1313 force-pushed the improvement/MID-8802 branch from fbc0d61 to d408643 Compare June 18, 2026 10:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MID-8802 Added displayName and preferredName to UserType#621

MID-8802 Added displayName and preferredName to UserType#621
kay1313 wants to merge 3 commits into
masterfrom
improvement/MID-8802

kay1313 commented Apr 23, 2026

Uh oh!

1azyman left a comment

Uh oh!

1azyman Apr 29, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

1azyman Jun 16, 2026

Uh oh!

kay1313 commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

kay1313 commented Apr 23, 2026

Summary

Core behavior

Scope of changes

What was intentionally NOT changed

Notes / impact

Result

Uh oh!

1azyman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kay1313 commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants