Private Staff Note Visibility

Dragwyb Click to Chat stores private staff notes separately from customer-facing ticket messages. In the inspected plugin version, internal notes are managed through staff-only support endpoints, and the customer portal response filters internal notes and staff-only metadata before returning a ticket. If a customer appears to see a private staff note, treat it as a potential privacy issue and verify the actual response and user permissions before continuing normal support work.

1. Stop and verify the affected ticket

Do not add further sensitive information to the affected ticket until you understand what the customer can see.
Record the ticket ID and the exact note/message that appears to be exposed. Avoid copying private customer information into public reports or screenshots.
Open the ticket as an authorized staff member and confirm the item was created using the internal-note control, not the customer reply composer.
Sign in with a separate test customer account and open only a ticket that account is authorized to access.

2. Confirm how the note was created

The support-note service stores internal notes under a dedicated metadata key and checks the staff member’s internal-note permission and access to the ticket. The staff-note endpoints also check ticket access. If the content was added through a normal reply instead of the internal-note control, it may be a customer-visible message rather than a private note.

3. Check the customer-facing portal response

The customer portal ticket-detail endpoint authorizes the visitor for the requested ticket and passes the record through a filter that removes internal notes, tokens, and staff-only metadata. Test the affected flow using the public portal and the same type of customer session that reported the issue.

Verify that a private note does not appear in the customer-facing conversation timeline.
Check whether the issue occurs only in one page builder template, cached page, or custom theme integration.
Compare the result in a private browser session after clearing the page cache, without reusing an agent session.
Do not use an administrator’s logged-in browser as proof of what a customer sees.

4. Review staff permissions and customizations

Review the Support Center role-permission configuration, especially the internal-note capability and which staff roles can access the ticket. If the site has custom code, a child-theme override, a modified portal template, or an integration that returns ticket data directly, verify that it does not bypass the plugin’s customer-facing filter.

5. If the note is still visible

Temporarily disable the affected custom integration or portal customization on staging, if one is involved.
Reproduce the issue with a test ticket and a customer account that does not have staff permissions.
Capture only redacted evidence and review the response returned by the customer portal endpoint.
Update the plugin to the intended current release if the installed files differ from the inspected source, then retest.
Do not resume storing sensitive internal information in notes until the exposure has been understood and resolved.

Related guides

Security note: The source includes filtering and permission checks, but this documentation update does not prove that your live site is secure. Test with a separate customer account and investigate any reproducible exposure before production use.