最近搜索
没有最近搜索

Joel Boonstra
已加入2021年5月13日
·
最后活动2022年8月10日
关注
0
关注者
0
活动总数
2
投票
0
订阅
1
活动概览
标记
文章
帖子
社区评论
文章评论
活动概览
的最新活动 Joel Boonstra
Joel Boonstra 进行了评论,
I've just now encountered this behavior in the real world. I discovered that a ticket (which was *not* ready to be solved) was inadvertently solved via Rapid Resolve when one of our agents clicked the pop-up. I only discovered it by happenstance a few weeks later while doing some auditing.
What was very confusing is:
- The rapid resolve events are attributed to the customer, not the agent
- All articles involved (both the unhelpful and helpful ones) were internal, and so I had a moment of panic when I thought that our customer was viewing internal articles
I eventually decided (after verifying article permissions) that this must have been some sort of weirdness with the token-based URLs. Today it happened to me and I found this article, describing a problem that has potentially very significant customer-facing ramifications that's now about 3 years old.
Furthermore, there's no obvious way to get rid of the pop-up if you are an agent, short of marking an article as solving the problem. This is probably why agents eventually mark something as solved, just to get rid of the pop-up.
Initially I thought/hoped I could get rid of the pop-up just by logging out and back in again, but that didn't seem to do the trick. Ultimately I was able to get rid of it by clearing site data for our apex domain (e.g. our help center is at help.DOMAIN, and I removed cookies / site data for DOMAIN, via Firefox tools). I don't know where exactly the customer-identification token is stored, but that does seem to have been necessary to clear the pop-up out.
I'm glad to have found this post so that at least I know I'm not the only one. I'm disappointed that a critical bug has existed for at least 3 years without any fix.
查看评论 · 已于 2022年1月07日 发布 · Joel Boonstra
0
关注者
3
投票
0
评论