You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
It would be useful to have a config-driven way to disable Hoist's feedback feature.
hideFeedbackItem
in app code.Also useful to be able to spec an alternate email for feedback in the same config.
null
, would continue to send toxhEmailSupport
as it does now.none
would disable feedback emailsemailOverride
to clarify that thenull
value will still send mails? Thenone
case kinda weird there too. Not sure what is best here, worth a little bit of thought.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
andxhFeedbackEmail
. 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.The text was updated successfully, but these errors were encountered: