Tag mapping UX todos

[cben]

Extracted from ManageIQ/manageiq#7460 (comment)
Some of these are purely UI, some involve backend too (but from user's perspective)...
cc @djberg96

Context: Tag mappings are defined via top right menu -> Configuration -> Region in explorer -> Tags tab Map Tags sub-tab.

---

Dumping my 2016 paper notes on UX loose ends:
Most of these reflect actual misunderstandings I saw QE and Doc team have deciphering the UI...

• Mapped tags are listed under "My Company Tags" on an entity page, despite being distinct from the manually assigned tags you configure in "My Company Categories/Tags" settings.

• When you see some mapped tags and try "Edit Tags", they're not there. This is intentional but confusing, would be better to include them but greyed out (and not allow changes).

• Currently it's unclear what to type in "Label" field. Nothing there suggests it's the key part of a label. (Users don't necessarily have a clear mental model of labels having key, value parts!)

  • [Feature Request] Provide drop-down list of category selections for tag mapping #772 — Label name should be dropdown offering existing label keys. Will be faster to use, reduce typos, and make it clearer.
  • Perhaps should also call the field "Label key" instead of "Label"?

• "Choose a category" may sound like you should type name of an existing category. Something like "Category name to create" could be clearer.

• Flash message confirming mapping was created/updated should explain that it will take effect only on next refresh.

• Can't map a given label to a given category for 2 entity types (eg. only pods & images). Can 1 type, or all of them. Can map 2 types to different categories.

  • I suspect the whole entity restriction is useless. No harm in always mapping same label everywhere?
    However different mappings by provider type (containers vs amazon) might be useful.

• UPDATE: I think this one is obsolete, I implemented coercing to lowercase at some point. Though I'm not sure whether of keys, values or both?

  If you have labels with inconsistent key case ("KEY=..." vs "key=..."), you can't map them both at all. UI won't let you even map them to different categories, and what you probably want is mapping to same category.
  We wanted this to keep simpler predictable category names. We could keep that but coerce all keys to lowercase (so a "key" mapping would always also cover "KeY" etc) — I think that'd be better than

  Before touching anything wrt. case handling, it'd be nice to understand how case works with direct use of labels in search/policy/reports — https://bugzilla.redhat.com/show_bug.cgi?id=1382720.

[cben]

FYI @Fryguy @AlexanderZagaynov @juliancheal

[cben]

Per discussion on gitter, it's clear that current "All or 1 type" dropdown + current 1 mapping : 1 category approach are too limiting. (*)
Relaxing the latter (many mappings to 1 category) is big UI project, both design and coding.
Alexander proposed making type options more granular, specific adding "All Vms" vs "Amazon Vms" or "Azure Vms" vs "All". I like this a lot 👍 Does need backend change but minor.

I propose to generalize this a bit, having separate (provider, type) columns. We discussed this when adding Amazon but punted because backporting...
Each could be specified or nil. ('azure', 'Vm'). ('amazon', nil) for Amazon vms and images. (nil, 'Vm') for all vms. (nil, nil) for everything.
UI could also have 2 orthogonal dropdowns, and 2 table columns when viewing list of all mappings (?)
Perhaps can write code mostly pretending we have 2 columns, just encode them into 1 for backportability (and later migrate to 2 real columns)...

[cben]

cc @bronaghs. If we improve granularity of what to map, is it important to backport that too? Or perhaps minimal support on fine + master-only improvements?

[cben]

I want to qualify "are too limiting" conclusion above. I meant ability to constrain entity type is barely usable. If you do, you corner yourself into various problems.

However, for most users, it'd be OK to only work with "All" mappings. If you have Vms with azure tag "office" AND openshift builds labeled "office", both will be tagged in same category, but in most contexts you don't care! E.g. in a report on vms by office category, you won't see container builds...

In fact, I think reducing granularity is a sane alternative! 🔥 ✂️ drop the Entity type dropdown?!
Why do I think it's sane? Because we have another feature, with zero configuration — custom attributes are visible as virtual "columns". No mappings to define, no planning, just build the report you want (I think also available in other places? in any MiqExpression? not sure exactly). Trivial, discoverable, perfect. ✨

Did I mention I'm not sure what's the use case for tag mapping now?

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[cben]

@miq-bot remove-label stale
not sure when/if anyone will work on these but they're still issues.

---

• New terminology issue from https://bugzilla.redhat.com/show_bug.cgi?id=1575068:
  Azure "tags" have "name" & "value".
  Amazon "tags" have "key" & "value".
  Kubernetes "labels" have "key" & "value".

  How can we have terminology in UI (and docs) that would work for all?

  To make things extra confusing, the feature maps Azure/Amazon "tags" into CloudForms "tags" so we shouldn't even used the word "tag" without qualification.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[miq-bot]

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

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the traige process documentation.

[miq-bot]

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

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the triage process documentation.