https://bugs.kde.org/show_bug.cgi?id=520107
Khudoberdi Abdujalilov <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Khudoberdi Abdujalilov <[email protected]> --- Worth flagging that some of this already works, though it's easy to miss. If the messaging app attaches a "Copy code" action to its own notification (Google Messages does), KDE Connect grabs that action and copies the code to the clipboard locally. That's NotificationsPlugin::copyAuthCodeIfPresent. So for those apps the quick copy is already there today. What's missing is everything else. Banks, and a lot of regional apps, send the SMS as plain text with no copy action, and nothing is offered for them. On the reporter's question about whether Android hands over the code: it doesn't put a dedicated OTP field in the forwarded notification, so the only way to cover these is to find the code in the message text on the desktop side. I've got a prototype doing that. It's a small detector that spots an OTP in the notification text and adds a "Copy code NNNN" action, but only when the phone didn't already provide one. The matching logic is a C++/QRegularExpression rewrite of AOSP's NotificationOtpDetectionHelper: first it looks for the shape of a code (4-8 digits, or alphanumerics with separators), then it throws out the things that look like codes but aren't, mainly dates, phone numbers and years. That last part is why it won't stick a copy button on every price or order number. No keywords, no per-language logic, same spirit as the existing copyAuthCodeIfPresent. Copying goes through KSystemClipboard, and the data is marked secret so clipboard-history tools don't hang onto the code. The 62 unit tests I ported from AOSP's own test corpus pass. Two things I'd like to settle before opening a merge request: 1. Do you actually want this - detecting the code in the message text to cover apps that don't send a copy action, rather than keeping OTP copy tied to app-provided actions only? 2. There's an obvious next step after this: only show the button when a context word ("code", "код", and so on) sits near the number, which kills the last false positives like a bare order number. Sonnet already does language detection and would fit. Is bringing Sonnet into the notifications plugin okay, or would you rather the detector stay on Qt Core alone? Either way I'm happy to send the MR once you've had a look. -- You are receiving this mail because: You are watching all bug changes.
