Feature request: able to manually add keywords to parse

[tomatojam42]

Hello.
Well, all is in the title of issue.

I receive sms in russian and without any special tags like <#>.
Just ваш код: 654321
Also may be код подтверждения, код доступа and so on.
And otphelper not parse it.

Such ways to deal with it:

1. Every not-English-speaking guy, who wants to use otphelper, creates his own wordlist or/and algoritm right inside an app.
   1.1. And if we are all kindful people, then we have to share the wordlist for improving the tool.

2. I may to collect my sms, analyse and create algorithms, like so for English or Arabian if any.

Or app is running simply as (WATCH PATTERN <#>) ?

[jd1378]

hi
the special tag in your case is the word код probably. but I do not know that, but you can confirm if when код is present, there's usually a code or not. then we can add it to the list

surely there is a list of sensitive keywords, parsed as a regex, found here
then the regex is executed on the entire notification string. if a match is found, the code is extracted

keeping your own list of sensitive words or in other words, letting user manage the list, is another way to do it, but creating an issue and contributing to the source code helps everyone on capturing the codes, not just yourself. and we can add more tests over time and ensure that adding/removing something does not break the code extraction of already known messages.

[jd1378]

Currently I don't have time to add this new feature, but if someone adds such a feature in a PR, in a way that is updatable by updates, while keeping user data/settings, and providing a good UX, I would be happy to merge it (please state that you are going to work on it if you are going to, before doing it, to avoid problems later)

meanwhile, should we add код ?

[jd1378]

I've added код in v1.3.0
please open another issue if you need other words to be added as well

[nvllz]

Hey @jd1378, I really like your app. But I think the way you handle keywords is too static. In order to get something to work in other languages or code types, you have to raise a PR here and wait for a new release. If you drop this project one day, new users will not find this app usable. Also, you're making the app available through different app stores, which in the case of googleplay means that most users may not have a github account and know how to make the app work for their keywords. Please consider a custom list of keywords that will also be useful for testing. People who want to contribute will continue to do so, but making the usability of the app completely dependent on releases and fixed strings in the repo is not future-first.

Thanks for the app, I hope to be able to use it with my own keywords that may not be suitable for others.

[jd1378]

Hi @nvllz
I'm somewhat against the idea personally, due to reasons I pointed out above, but the main reason is I don't have the time to add new features

Either the project needs to have financial support for me to put more time on it, or have contributors help me in adding features or improving the app
Otherwise It usually takes my free times to develop the features

[nvllz]

Sure, I understand your point of view. You spent some time developing it and you want it to be used on your terms. I just wanted to point out that the current way of managing keywords will probably cost you more time with more keywords to add and possible unwanted detections by others, meaning more PRs/issue tickets for individual words. You've made a very useful application, but the end user can't control the keywords manually (there's probably an option to blacklist some notifications, but I couldn't test it), and that's a problem. No offense to you, just saying how I see it. I couldn't even test it because the app doesn't handle the keywords I want. And while it may be useful for me to have them copied automatically, others may find it annoying and make a PR to undo my changes.

A custom keywords list would give longevity to the project, as you seem to not accept donations and may just stop development one day. I just want you to think again and change your mind, because this kind of static attitude may cost you more attention, and since you don't have much time, new keyword PRs will not be addressed. Cheers.

[jd1378]

I understand and I try to implement the feature, just that it may take a while
thanks for the feedback :)

[pataquets]

@jd1378 First and foremost, I'm using the app and it's great. So nifty and useful!
Thank you very much for sharing your effort in crafting such a fine piece of software.

Just because of its usefulness, just dropping another solution to a problem stated above.
(Once|if) the app grows enough in user base, consider moving it into a Github organization, in case sometime in the future you fancy adding collaborators to even handing off the app completely.
Not necessarily now, just pointing out the alternate solution to changes in your availability/commitment/interest/whatever-you-feel-like.

[sbellon]

I also second the idea of having per-user configurable keywords. While the idea of having it hard-coded "for the benefit of all" sounds charming at first, there is no "one size fits all" solution and you will not be able to please everyone.

E.g. in your static list, there already is Einmalkennwort but Kennwort is missing. I could directly see that also something like Einmalpasswort, Passwort and Password may be useful. If users can configure this for their own usage, they can fine-tune it for the apps they use, not get false positive notifications and you remove the maintenance effort from your app.

[jd1378]

Hi
I wanted to wait a bit before announcing it, since there's still much to do,
But I'm working on it and the feature plus history of detection (+ highlighting what caused detection and what was detected) will be added in the coming weeks

Thanks for helping improve the app with your suggestions

[pataquets]

That's great, @jd1378! Thank you.
I'd like to point out that some "copy detection string expression/regex/whatever" kind of feature would help those wanting to contribute back their custom detection strings, once they have fine-tuned themselves. Sure, it's not a killer feature nor deal breaker, but worth sharing 2c here at least, IMHO.

[jd1378]

Good idea, sounds useful for testing for example on regex101.com

[jd1378]

Hi
a release candidate was released:
https://github.com/jd1378/otphelper/releases/tag/v1.16.0-rc

please try and let me know if you have any issues

[jd1378]

Hey,
I have released v1.16.0-rc3 which resolves some of the issues and adds more features
please try it when you have time

[jd1378]

sorry for the notifications
I have released v1.16.0-rc4
which contains some important fixes for reliability of the app (if you had issues with app not working after some time and reopening it did not help)

this is probably the final rc (rest is waiting for translators to translate the new entries)

[sbellon]

I have added new keywords and removed default ones. Works fine for me so far. 👍