fix: clarify custom message settings UX - #22
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Improves the LimeSurvey settings UX around Telegram text messages.
The current form always shows the parse mode and message template even when Send message is disabled. This makes it easy to edit a template and assume it will be sent, while the plugin silently skips the text message unless the checkbox is enabled.
This change:
Why
While configuring a real survey, it was possible to fill in a custom template without noticing that the separate SendMessage checkbox was still disabled. PDF and CSV attachments were delivered, but the text message was not. The UI should make this dependency explicit instead of requiring users to infer it.
Expected UX
The settings order is intentional:
When Send a custom message is off:
When it is enabled:
Testability
The UI behavior is no longer embedded only as an inline block inside the plugin class.
This gives us both backend/unit validation and frontend/browser validation for the behavior that caused the original UX issue.