Repository navigation
Say in the ticket body when nothing vouched for the requester - #132
zamanafzal wants to merge 1 commit into
Conversation
The name and username custom fields read identically whether a session supplied them or the learner typed them into a chat box on a public page. The unverified tag said so, but an agent about to act on a ticket reads the body, and a tag is easy to miss on a crowded ticket view. Put the same warning in the body, saying only that nothing on the filing request confirmed the requester: the email, name and username can each come from an earlier turn in the thread, so naming where they came from would be wrong. The page-url test compares the body exactly again, filing as a verified requester so no note is appended.
![agent-optibot[bot]](https://avatars.githubusercontent.com/in/934808?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary
Support tickets from unverified requesters now visibly warn Zendesk agents not to trust submitted identity details. The warning is added to ticket bodies alongside the existing requester tag, while verified tickets remain unchanged.
Key Changes
- Unverified requester tickets now include an explicit identity warning in the comment body.
- Verified requester tickets retain their existing body content without additional warnings.
- Tests verify warning behavior across requester verification states and preserve original ticket content.
All Relevant File Changes (click to expand)
- ai_chatbots/constants.py: Defines reusable warning text for unverified requester identities.
- ai_chatbots/zendesk.py: Appends identity-verification warning to ticket bodies when email is unverified.
- ai_chatbots/zendesk_test.py: Covers warning presence, absence, and ticket-body preservation across verification states.
💬 Feedback & Commands
Share feedback on my comments with 👍 👎 — I'll stop raising issues you push back on. Think I missed something? Adjust my sensitivity →
5 things I can do →
#optibot review— I'll re-review your latest changes (incremental)#optibot full review— I'll re-review the entire PR from scratch#optibot fix— I'll apply my suggested fixes to your code#optibot compliance— I'll run a compliance check on your changes#optibot release notes— I'll write up release notes for your production release
💡 Tip: I can audit every dependency change before it reaches main — one compromised package can take down your entire system. Try Supply Chain Agent.
- 🔄 re-review this PR
There was a problem hiding this comment.
Summary
Support tickets from unverified requesters now clearly warn Zendesk agents that requester identity details are unconfirmed. The warning appears in the ticket body alongside the existing requester tag, with tests covering verified and unverified submissions.
Key Changes
- Adds an explicit unverified-requester warning to support ticket bodies.
- Preserves requester verification tagging while warning agents who primarily read ticket content.
- Tests warning inclusion for unverified tickets and omission for verified tickets.
All Relevant File Changes (click to expand)
- ai_chatbots/constants.py: Defines the reusable Zendesk warning text for unverified requester identities.
- ai_chatbots/zendesk.py: Appends the warning to ticket bodies when requester email verification is absent.
- ai_chatbots/zendesk_test.py: Updates ticket tests and verifies warning behavior for both verification states.
💬 Feedback & Commands
Share feedback on my comments with 👍 👎 — I'll stop raising issues you push back on. Think I missed something? Adjust my sensitivity →
5 things I can do →
#optibot review— I'll re-review your latest changes (incremental)#optibot full review— I'll re-review the entire PR from scratch#optibot fix— I'll apply my suggested fixes to your code#optibot compliance— I'll run a compliance check on your changes#optibot release notes— I'll write up release notes for your production release
💡 Tip: I can audit every dependency change before it reaches main — one compromised package can take down your entire system. Try Supply Chain Agent.
|
Optibot: trial review limit reached Your organization has used all 300 code reviews included in your Optibot trial, so this pull request was not reviewed. Upgrade to resume automatic reviews: https://agents.getoptimal.ai/dashboard/billing |
What are the relevant tickets?
Closes https://github.com/mitodl/hq/issues/13985
Description (What does it do?)
A support ticket filed on a request that carried no session now says so in the comment:
The intake route takes the name, username and email from the request body when there is no session, so the launcher works on a logged-out page. Those values land in the same Zendesk custom fields that a signed-in learner's verified values use, and read identically there. The
tim_unverified_requestertag already marks the ticket, but a tag sits in the sidebar alongside every other tag the account uses, and an agent about to act reads the comment.The tag is unchanged — the note is in addition to it.
Split out of #98, where it was raised in review (#98 (comment)), and held until that merged.
Implementation details
The note goes on in the same
if not email_verified:branch that appends the tag, so the two can't disagree.Its wording says nothing about where the values came from, only that nothing on the filing request confirmed them. That distinction is load-bearing:
email_verifiedis deliberately per-request, while the email, name and username can each come from an earlier turn in the thread (_support_emailand_accumulatedinai_chatbots/chatbots.py). On a thread whose earlier turn was signed in and whose filing turn is not — the casetest_support_bot_does_not_inherit_verification_from_an_earlier_turnalready covers — a note claiming the learner typed these values would be false.An unverified ticket's comment is already private and its subject already replaced with
ZENDESK_UNVERIFIED_SUBJECT, both from #98, so the note reaches agents rather than a notification email sent to an address nobody has proved belongs to whoever typed it.How can this be tested?
test_file_support_ticket_says_in_the_body_who_vouched_for_the_requesteris parametrized onemail_verifiedand reads the posted payload: note present when false, absent when true. Deleting the one line inzendesk.pyfails the[False]case and leaves[True]passing.Not exercised against a real Zendesk. That needs OAuth credentials and the custom field ids, which no deployed environment has yet (https://github.com/mitodl/hq/issues/13991), and stub mode returns before the comment body is built so it cannot show the note either.
Additional Context
The note is appended after the learner's own text, so a long description pushes it down the comment and a learner can write a lookalike line just above it. That's deliberate — the problem should read first, and the tag remains the signal nothing in the request body can forge.