You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
jrnl: v3.3
Python: 3.11.1 (tags/v3.11.1:a7a450f, Dec 6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
OS: Windows 10
Current Behavior
Pretty much any combination of --change-time, --delete, and --edit in the same jrnl call leads to unpredictable results.
We have a couple issues about very specific combinations (#1639, #1644), but I wanted to file a broader issue around this to precisely specify the expected behavior so users reading the changelog know what to expect without digging into the code or PR comments.
Expected Behavior
When I run any combination of --change-time, --delete, and --edit, I expect this result, in this order, on the whole journal, or just in the search results if I use search criteria in my jrnl call:
If I entered --change-time, I will first be prompted to change the time of each entry
If I entered --delete, I will then be prompted to delete each each entry
If I entered --edit, my editor will open with the results of the previous actions, and I can modify, remove, or append entries in my editor.
When this is finished, I will see a precise count of each entry added, modified, or deleted by all the actions above.
Repro Steps
I've already specified this in a BDD test for our test journals, which start out with 3 entries:
Scenario Outline: Combining --change-time and --delete and --edit affects appropriate entries
Given we use the config "<config_file>"
And we append to the editor if opened
[2023-02-21 10:32] Here is a new entry
And we use the password "test" if prompted
# --change-time is asked first, then --delete, then --edit
When we run "jrnl --change-time '2022-04-23 10:30' --delete --edit" and enter
N
Y
Y
Y
Y
N
Then the error output should contain "3 entries found"
And the error output should contain "2 entries deleted"
And the error output should contain "1 entry modified" # only 1, because the other was deleted
And the error output should contain "1 entry added" # by edit
When we run "jrnl -99 --short"
Then the output should be
2022-04-23 10:30 The third entry finally after weeks without writing.
2023-02-21 10:32 Here is a new entry
Debug output
n/a
Other Information
No response
The text was updated successfully, but these errors were encountered:
Diagnostic output
jrnl: v3.3
Python: 3.11.1 (tags/v3.11.1:a7a450f, Dec 6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
OS: Windows 10
Current Behavior
Pretty much any combination of
--change-time
,--delete
, and--edit
in the same jrnl call leads to unpredictable results.We have a couple issues about very specific combinations (#1639, #1644), but I wanted to file a broader issue around this to precisely specify the expected behavior so users reading the changelog know what to expect without digging into the code or PR comments.
Expected Behavior
When I run any combination of
--change-time
,--delete
, and--edit
, I expect this result, in this order, on the whole journal, or just in the search results if I use search criteria in my jrnl call:--change-time
, I will first be prompted to change the time of each entry--delete
, I will then be prompted to delete each each entry--edit
, my editor will open with the results of the previous actions, and I can modify, remove, or append entries in my editor.Repro Steps
I've already specified this in a BDD test for our test journals, which start out with 3 entries:
Debug output
n/a
Other Information
No response
The text was updated successfully, but these errors were encountered: