Allow Metagrid deployers to configure a local support contact

[lliming]

Is your feature request related to a problem? Please describe

The Globus support team (support@globus.org) is receiving a slow-but-steady stream of support tickets from people using Metagrid. Some of these issues have to do with application logins being misconfigured and others with Globus transfers being misconfigured. The ticket reporters are using Metagrid deployed at LLNL, ORNL, and (most recently) NCI (Australia). So far, none of these issues have been things the Globus support team can help with: they’re all Metagrid misconfigurations. (E.g., using a bad Client ID, misconfigured redirect URL in Globus Auth registration, etc.) The fixes need to be applied by the people who deployed Metagrid.

Part of the problem is that Globus's error message instructs the end user to contact support@globus.org. (I'm following up separately with Globus about this.)

But another part is that Metagrid doesn't provide a way to find out who to contact about the specific Metagrid deployment. (If it was provided, the Globus support team would use that information to reach out to the application deployer to resolve the issue.)

Describe the solution you'd like

Metagrid should have a configurable that the deployer can set, providing contact information for technical support with this deployment of Metagrid. The configured information should be prominently displayed on the Metagrid application's Help page.

A default value should likely be something that informs the end user that the operator of this Metagrid application hasn't provided support contact information. (I propose this because it will, hopefully, encourage the deployer to do the right thing and provide a support contact.)

Describe alternatives you've considered

I don't think there is any alternative? On general principle, publicly available applications should tell their users how to get help. Since this application is deployed by several teams, the support contact has to be configurable by the deployer?

Additional context

At present, the Help feature in Metagrid offers this:

Welcome to Metagrid Support! To view the latest documentation and FAQ, please visit this page:
https://esgf.github.io/esgf-user-support/metagrid.html

The page above has a lot of references to LLNL an ORNL. But of course Metagrid is intended to be deployed multiple places, so those references may not be relevant? Since it's linked to from Metagrid's Help page, the page should be reviewed with an eye to, "Is this page useful to people who get directed here from a random Metagrid deployment?"

If you need help on Globus Transfers (following successful submission to Globus), please visit this page for more information: https://app.globus.org/help

The context here is helpful! Globus likely is the best place for these kinds of issues.

and this:

Questions, suggestions, or problems? Please visit our GitHub page to open an issue. https://github.com/aims-group/metagrid/issues

The Github repo is for reporting code issues, but of course only a subset of the issues end users experience using a Metagrid deployment are code issues. (Some are configuration or deployment issues.) Since this is an aims-group organization repo, it seems unlikely that the people who deploy Metagrid locally are watching issues here? This is likely where we should see the local deployer's support contact information?

[sashakames]

I think that is a good idea if desired by the site. For now (1) users use the link.
(2) from that site there is a link to this page https://esgf.github.io/esgf-user-support/faq.html co-located with the linked page that contains the general ESGF support email. I was reluctant to include that as an option as we want users to email as a last resort and prefer they read the docs first.

[bstrdsmkr]

Metagrid should have a configurable that the deployer can set, providing contact information for technical support with this deployment of Metagrid. The configured information should be prominently displayed on the Metagrid application's Help page.

A default value should likely be something that informs the end user that the operator of this Metagrid application hasn't provided support contact information. (I propose this because it will, hopefully, encourage the deployer to do the right thing and provide a support contact.)

As an immediate step, the footer is configurable, so that could be used until The Right Answer™️ makes itself known? As far as what that answer is, I'm certain I read an RFC for a standard for providing technical support avenues somewhere... I'll see if I can dig that up and if it looks feasible here.

Questions, suggestions, or problems? Please visit our GitHub page to open an issue. https://github.com/aims-group/metagrid/issues

Since this is an aims-group organization repo [...]

Just a side clarification that that link actually comes to this repo since metagrid was transfered to the esgf2-us organization. Link still needs to be updated for sanity reasons though

we want users to email as a last resort and prefer they read the docs first

agree w/ @sashakames here -- I kind of view the number of support contacts as a makeshift telemetry. If we're getting contacts, it represents a failure in the UX (usually in documentation since the errors are going to happen). I'd rather fix up the UX through better design or documentation than easier access to human intervention

I'll also note though that this isn't "a Metagrid problem," rather Metagrid is just the first victim. It's a problem we need to solve across all of our user facing services, so finding the right solution has a high impact

[sashakames]

:-D Thanks for pointing out that link has the legacy aims-group - that is easy to fix for consistency, as the org transfer occurred ages ago.