When working on knotes patch it was discovered that knotesapp causes LAST-MODIFIED field to be updated.
Steps to reproduce
Close knotes
Save a copy of notes.ics
Open knotes
Do diff on both files
Screenshots
<!--
This is a comment.
Please fill in the required fields below.
The comments provide instructions on how to do so.
Note: You do not need to remove comments.
-->
## Basic information
- TDE version: 14.1
- Distribution: Debian Buster
- Hardware: amd64
<!--
Use SL/* labels to set the severity level.
Please do not set a milestone.
-->
## Description
When working on knotes patch it was discovered that knotesapp causes LAST-MODIFIED field to be updated.
## Steps to reproduce
1. Close knotes
2. Save a copy of notes.ics
3. Open knotes
4. Do diff on both files
## Screenshots
<!-- If it seems useful, please provide provide one or more screenshots. -->
I think the ics file is updated on exit, not on start. So the correct steps to reproduce should be:
Save a copy of notes.ics
Open knotes
Close knotes
Do diff on both files
I think the ics file is updated on exit, not on start. So the correct steps to reproduce should be:
1. Save a copy of notes.ics
2. Open knotes
3. Close knotes
4. Do diff on both files
I was also thinking the same - but the work around shows it is when loading - also the debug I did shows setLastModified() is called 2-3 times when loading.
I was also thinking the same - but the work around shows it is when loading - also the debug I did shows setLastModified() is called 2-3 times when loading.
Nope, I just tested it again. The ics file is definetely modified when knotes is closed.
Probably the value is updated on loading as you have described (when title or content of the knote widget is set) and later saved to file when the program is closed.
Anyhow we are talking about the same issue 😄
Nope, I just tested it again. The ics file is definetely modified when knotes is closed.<br/>
Probably the value is updated on loading as you have described (when title or content of the knote widget is set) and later saved to file when the program is closed.<br/>
Anyhow we are talking about the same issue :smile:
Try adding debug around the loading and also in the ikcal when calling setLastModified.
You will see when the loading is done it also calls the setLastModified().
It might be I am wrong as I observed this when working on the patch, of course, but I am wuite sure this was the reason for the workaround at that place.
Unfortunately the code is spagetti and not easy to read - at least for me.
thank you in advance
Try adding debug around the loading and also in the ikcal when calling setLastModified.
You will see when the loading is done it also calls the setLastModified().
It might be I am wrong as I observed this when working on the patch, of course, but I am wuite sure this was the reason for the workaround at that place.
Unfortunately the code is spagetti and not easy to read - at least for me.
thank you in advance
Emanoil, I have prepared PR #40 where I propose a different solution rather than a workaround. This consist in avoiding to incorrectly update the journal when loading a note from an .ics file.
I have tested locally, appreciate if you could test as well before we proceed with a merge.
EDIT: more work is required for fixing Kontact too.
Emanoil, I have prepared PR #40 where I propose a different solution rather than a workaround. This consist in avoiding to incorrectly update the journal when loading a note from an .ics file.<br/>
I have tested locally, appreciate if you could test as well before we proceed with a merge.
EDIT: more work is required for fixing Kontact too.
Basic information
Description
When working on knotes patch it was discovered that knotesapp causes LAST-MODIFIED field to be updated.
Steps to reproduce
Screenshots
I think the ics file is updated on exit, not on start. So the correct steps to reproduce should be:
I was also thinking the same - but the work around shows it is when loading - also the debug I did shows setLastModified() is called 2-3 times when loading.
Nope, I just tested it again. The ics file is definetely modified when knotes is closed.
Probably the value is updated on loading as you have described (when title or content of the knote widget is set) and later saved to file when the program is closed.
Anyhow we are talking about the same issue 😄
It is setting also colors - may be this is root cause. I checked the text and title.
Try adding debug around the loading and also in the ikcal when calling setLastModified.
You will see when the loading is done it also calls the setLastModified().
It might be I am wrong as I observed this when working on the patch, of course, but I am wuite sure this was the reason for the workaround at that place.
Unfortunately the code is spagetti and not easy to read - at least for me.
thank you in advance
I will take a look during the week, want to close this point quickly if we can 😄
I will take a look during the week, want to close this point quickly if we can 😄
This is my experiment
(added debug in setLastModified in libikcal) and in resource local.
Seems that
manager()->registerNote( this, *it );
is triggereing this.Emanoil, I have prepared PR #40 where I propose a different solution rather than a workaround. This consist in avoiding to incorrectly update the journal when loading a note from an .ics file.
I have tested locally, appreciate if you could test as well before we proceed with a merge.
EDIT: more work is required for fixing Kontact too.
Fixed by PR #40.