Has any progress been made on this?
Instead of supporting unlimited number of days, would it make sense to implement an expiration logic a bit similar to backup applications?
For example (from rsync-time-backup)
Backup sets are automatically deleted following a simple expiration strategy defined with the --strategy flag. This strategy is a series of time intervals with each item being defined as x:y, which means "after x days, keep one backup every y days". The default strategy is 1:1 30:7 365:30, which means:
- After 1 day, keep one backup every 1 day (1:1).
- After 30 days, keep one backup every 7 days (30:7).
- After 365 days, keep one backup every 30 days (365:30).
Before the first interval (i.e. by default within the first 24h) it is implied that all backup sets are kept. Additionally, if the backup destination directory is full, the oldest backups are deleted until enough space is available.
Would there be any interest in that kind of feature?
3 Likes
This, IMO, would be a very effective system to use.
That is true, the slider is already a pain to use. Why not replacing it with a simple number field and allowing 1 ... 999, but also 1k ... 100k ?
1 Like
I would be interested.
+1 for unlimited number of days for note history.
Example: I accidentally deleted part of an old note that was made in 2019. I hoped that the note history actually work and corresponds to 90 days. That is, changes made in the last 90 days can be undone(!). But this did not happen - only my single erroneous change made over the past 90 days remained, and it can't be undone. Something is wrong with the logic, or it must be changed. The bigger number of days is not the solution in such case. Over time, there will always be a note that is older than the specified number of days. On the other hand, there could be notes that I change every day, and I don't need to keep their changes for decades to protect my old notes from accidents.
Maybe to keep always one more note older than note history period could be the solution ?
1 Like
How about this implementation?
Unlimited and indefinite note history
Add a Limit note history checkbox like website design - How to enable users to insert an infinity number - User Experience Stack Exchange. If unchecked, maximize the note history value. If checked, show the existing Keep note history for (days) as a numeric input on both desktop and mobile.
Add a separate Minimum revisions to keep numeric input for saving one or more note revisions indefinitely. This could prevent frustrations like what @HiBing0 experienced.
These features could work with or without the following:
Expiration logic
Split each strategy item into a rule label, Delete button, and After (days) and Keep 1 backup every (days) numeric inputs. Show an Add backup rule button below all rules if any exist.
If a fixed number of backup rules is preferred, replace the delete buttons with checkboxes (desktop) and toggles (mobile) that show and hide the inputs.
Either interface encourages easier understanding of the strategy and shorter, more mobile friendly input values.
Questions
Should spontaneous intraday note history throughout the Keep note history for (days) duration be preserved? If yes, how can that be achieved with this logic? Keep note history for (days) would act as a limit while the expiration logic dictates regular backup intervals.
1 Like
Now that Mobile: Resolves #10883: Remove slider component module and replace integer settings with new validated component has been merged and the slider has been removed is it possible to again consider to increase the limit for the note history?
2 Likes
It has been updated to 99999 days (ref this Github issue here) (tho I can’t yet update it to 99999 days).
You need to wait for Joplin 3.4 to set it to 99999 days on mobile. But it’s currently available as a pre-release.
The relevant PR is here: Desktop, Mobile: Extend the maximum note history expiry days to 99999 by mrjo118 · Pull Request #12374 · laurent22/joplin · GitHub
Would it be very difficult to just have an option to set it to "unlimited"? Obviously, the value of 99999 days is extreme and means basically just that, however it looks a bit like a hack 
. In other applications, I've seen terms such as "unlimited" or "forever" used in similar situations.
I think the issue is the configuration screens are generated somewhat dynamically, and at least on the mobile app, don’t have a way to conditionally show or hide a setting based on another setting, unless writing some overriding code or a separate screen (like is done with the plugins screen I believe). So it’s certainly possible, just that the code would be somewhat messy to integrate with the existing code for the settings screens and would hurt maintainability without some more significant refactoring