-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent parsing of narration field with respect to generating tags #1557
Comments
ok I believe I found where the logic is taking place which confirms my observed behaviour...just don't know how to fix it (of if it should be fixed...). Currently the only way I can think of escaping or avoiding my issue is in my csv importer is to have a custom extract that strips these (or modifies in other ways) prior to it getting to fava which is less then ideal IMO. https://github.com/beancount/fava/tree/main/frontend/src/entry-forms)/Transaction.svelte lines 48-61
|
I have tried to implement a workaround for this in my csv importers as I am already overriding the extract function their. I have the following test code where I let the base extract method parse the entries then I loop over the entries and do some matching to then handle in a way that eliminates the issues I am having by putting the establishment reference numbers into a metadata tag and then remove from the narration field. The issue I am having is nothing changes in the narration field when fava displays it. Does anyone know what I might be missing to get this to work? It is like fava is capturing its own narration field and can't change it from my csv importer.
|
Sounds good - PR welcome :)
The issue is that you never modify any of the |
thank you, I'd gladly do a PR but Java is not my swim lane at all and I am afraid to admit that I don't know how to do a PR.... I have been learning Python on my own and have git on the list to also get familiar with so I can be more useful for these kinds of things but have not gotten around to it yet. I have some ideas for a fix though....either 1) we merge the tags and links regexs into a single regex but this loses some flexibility and not sure if this would impact other things or 2) keep the tag and link patterns separated but strip them down to the essential and then dynamically combine them in the final regex that does the matching and removal. option 2 would be something like...
|
posting this for others in case they to need a way to sanitize the narration field for descriptions with store numbers in them to avoid them becoming tags. Below is my current working solution in the csv importer where I over-ride the extract function and use some regex's to detect and remove store numbers. I chose to store these store numbers as metadata as to not loose this information but certainly not necessary. This is a workaround for the time being until maybe a solution is implemented for more precise parsing of tags and links from the narration field.
|
In my csv importer, if I import the following record:
02/18/2023,RETAILER #89 TORONTO ON,92.78,
I get the following entry..
Which is ok...however if I import the same record and add a tag (or make any other edit) to the narration field during the fava import process things change. For example if I add the tag '#test' I now get the following:
What I would like is that the #89 (store number/identifier) to not be parsed as a tag but I get that the fava process does not know what is a real tag versus one that should be not considered a tag. I had thought maybe I could circumvent this by simply escaping the # but this is not a great way to do it. Using \ results in \ in my beancount file which then has downstream consequences and I also noticed that inserting a single space after the # also prevents it being parsed as a tag but again it does leave the narrative intact as read from csv which is what I would like.
I think the fava process that parses this string should only parse and collect tags starting from the end of the string and stop when it encounters a non-tag token. This would prevent the issues I am noticing and would also make consistent regardless if the narrative text was modified or not.
The text was updated successfully, but these errors were encountered: