Use product settings for docs & links

[mzazrivec]

Fixes #6083

[miq-bot]

Checked commit mzazrivec@b61ee1e with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.20.0, and yamllint
1 file checked, 0 offenses detected
Everything looks fine. 🏆

[himdel]

LGTM, removes the last uses of i18n.t from the UI 👍

(We still have..

manageiq/lib/vmdb/appliance.rb
37:      ::Settings.product.name || I18n.t("product.name").freeze

manageiq/app/models/dictionary.rb
38:    result = I18n.t("dictionary.#{type}.#{text}", :locale => "en")

manageiq-api/app/controllers/api/api_controller.rb
81:        :name_full            => I18n.t("product.name_full"),
82:        :copyright            => I18n.t("product.copyright"),
83:        :support_website      => I18n.t("product.support_website"),
84:        :support_website_text => I18n.t("product.support_website_text"),

manageiq-appliance_console/loads/and/loads/of/stuff

)

[bdunne]

Shouldn't these be in the core repo?

[bdunne]

Actually, the whole docs section feels like it belongs in core.

[Fryguy]

There are a number of things wrong with this, but

• Yes, I agree this entire section should live in core.
• All of the links should be https
• provider type links are fine, but then "ansible" (which should really be ansible_tower) is a provider specific link, which should be pluggable, but I'd argue that it shouldn't exist at all since we don't have any of the other providers
• top-level docs is a string, but :ui is a symbol

[himdel]

I think the point of the change was to use Settings instead of ui_lookup. Anything else is optional :).
(Note it didn't actually change any of the links, feel free to update them if you know what they should be.)

As for ansible - maybe it should really be automation. It's used in the "no records" screen in /automation_manager/explorer (Automation > Ansible Tower > Explorer)

[himdel]

(Except for product_support_*, none of the other keys are used anywhere outside the UI.)

[mzazrivec]

I'm having bit of a problem understanding why should this config section live in core?

[himdel]

IMO it doesn't make sense to move these to the core without a core mechanism for "get me docs for this model kind of provider" (infra/cloud/automation...),
and the UI won't consume it over the API before we have an API endpoint for list views with all the info the UI needs. (Should we plan for pluggable provider kinds?)

What am I missing? :)

[bdunne]

I opened https://github.com/ManageIQ/manageiq/pull/20010/files and #6793 to move the settings.

[bdunne]

ManageIQ/manageiq-api#788 is how I got here. Which struck me as odd that UI settings are being used for the API.

[Fryguy]

I think the point of the change was to use Settings instead of ui_lookup

Yeah, we're not disputing the usage of Settings, we're disputing where the Settings should live.

Anything else is optional :).

Totally agree...My list was not for this PR but for a follow up.

and the UI won't consume it over the API before we have an API endpoint for list views with all the info the UI needs. (Should we plan for pluggable provider kinds?)

Settings are already available via the API, and providers can already bring pluggable settings, though in this case they are actually provider-type which is a core construct anyway, so it doesn't matter.

[simaishi]

Removed jansa/yes? as this was merged before branch cut.