Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add xhFeedbackConfig to disable feedback, override email recipients #429

Open
amcclain opened this issue Dec 20, 2024 · 0 comments
Open
Assignees

Comments

@amcclain
Copy link
Member

  • It would be useful to have a config-driven way to disable Hoist's feedback feature.

    • This should be checked by hoist-react and avoid the need for developer to spec hideFeedbackItem in app code.
    • The admin console feedback tab should also display a message that the feature is disabled - believe we have this pattern in place for other optionally-disabled admin modules
    • It's possible someone might want to disable new feedback and yet still see old feedback, but I don't think we need to worry about that. Let's keep it simple and clear.
  • Also useful to be able to spec an alternate email for feedback in the same config.

    • If key not present in config or set to null, would continue to send to xhEmailSupport as it does now.
    • If key present and set to special mail token none would disable feedback emails
    • Wondering if it should be called emailOverride to clarify that the null value will still send mails? The none case kinda weird there too. Not sure what is best here, worth a little bit of thought.
xhFeedbackConfig: {enabled: true, emailOverride: null}

For the first feature to work, we would want to make this new config clientVisible. I don't think there's any issue with the email then also being sent to the client (despite the fact that it does not need it). It's a tradeoff of having the single JSON config with the single visibility setting - we could also decide to have separate configs, e.g. xhFeedbackEnabled and xhFeedbackEmail. We could decline to auto-create the second one in bootstrap - meaning it would only have an effect if manually created by an admin who knew you could do such a thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants