Fix request page tag value

[GilbertCherrie]

Fixes how dialog tag field values are displayed on the service request page.

Before:
The first tag dropdown is a multi-select with 3 values selected, but the request page only shows the first value.

After:
This PR fixes this bug to show all the selected values.

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[miq-bot]

This pull request has been automatically marked as stale because it has not been updated for at least 3 months.

If these changes are still valid, please remove the stale label, make any changes requested by reviewers (if any), and ensure that this issue is being looked at by the assigned/reviewer(s).

[jrafanie]

@GilbertCherrie sorry, I lost this one, what's the status on it?

[GilbertCherrie]

@Fryguy @jrafanie I updated this PR, and it should be good to go now. I left some comments in this code to remind us that if we ever fix the automation engine to return array values instead of strings separated by "\u001F" then we need to update the code for this file.

[jrafanie]

I'm not sure why we have \u001F as a string separator... does this align with what we're doing in

#9482
ManageIQ/manageiq-automation_engine#545

should this PR or 9482 be part of ManageIQ/manageiq-content#773, which has a list of a bunch of work items where some are completed.

[GilbertCherrie]

Instead of arrays, currently we use \u001F as a separator. This PR fixed this issue: ManageIQ/manageiq-automation_engine#545 and enabled arrays, but after problems were found, it was reverted. This PR is independent of ManageIQ/manageiq-content#773, which contains the work items that need to be completed to allow for arrays and get rid of \u001F. Once that is all done we then need a follow up PR in the UI-classic repo to handle the arrays instead of strings.

[jrafanie]

sent in chat, but if you can clarify in the 773 PR list of work items what work is done for the current way (this PR) and what is for the future way, (remove this separator and use arrays), as it's hard to follow what's fixing the current way and what's for the future (arrays) way.

[jrafanie]

ok, ManageIQ/manageiq-content#773 looks better. Thanks for clarifying.

[Fryguy]

I'm not sure why we have \u001F as a string separator

Essentially, if you have an Array of objects in automate, we used to serialize those as a comma-separated list (I think through the automation URIs, since automate uses URIs everywhere). This works fine for integers, but for strings, the strings could themselves have commas in them. So you'd have this problem where the user would create "abc", "def,ghi", "jkl", which would render to the URI as abc,def,ghi,jkl, and in turn be deserialized incorrectly. So, the decision was made to change both the automate side and the UI side to separate by \u001F instead of comma. The reason \u001F is chosen is because \u001F is defined as the "Unit Separator". (i.e. it's a control character specifically for this purpose of acting as a data separator). Since it's a control characters, it's incredibly unlikely to be in usable user data.

See ManageIQ/manageiq-automation_engine#484 (comment)
Original Issue: ManageIQ/manageiq-automation_engine#480

[jrafanie]

As discussed, we'll add cypress tests for this and the other pages in PRs linked in ManageIQ/manageiq-content#773 as we'll likely need to make some changes to make it work with arrays instead of delimited strings so it might make sense to get the expected page layout in cypress before doing that work so we can verify the page is correct when converted to use arrays.

[jrafanie]

@GilbertCherrie LGTM, can the rubocops be fixed or does it make sense to ignore them?

[miq-bot]

Checked commits GilbertCherrie/manageiq-ui-classic@b90708b~...50fdfdb with ruby 3.3.10, rubocop 1.86.0, haml-lint 0.72.0, and yamllint 1.37.1
1 file checked, 4 offenses detected

app/views/miq_request/_request_dialog_details.html.haml

• ⚠️ - Line 31 - 2 consecutive comments can be merged into one
• ⚠️ - Line 37 - 2 consecutive comments can be merged into one
• ⚠️ - Line 39 - Line is too long. [87/80]
• ⚠️ - Line 40 - Line is too long. [93/80]

[jrafanie]

LGTM, just waiting on green

[Fryguy]

Backported to tal in commit e8ad716.

commit e8ad716ebef28b146a063b63234024c2c61ee1c1
Author: Joe Rafaniello <jrafanie@users.noreply.github.com>
Date:   Wed Apr 8 15:32:23 2026 -0400

    Merge pull request #9250 from GilbertCherrie/fix_request_page_tag_value
    
    Fix request page tag value
    
    (cherry picked from commit 2302577ec3568906509ea952e94ffe498075db12)