Repository navigation
[FEATURE REQUEST] Optional sorting for property-list captures, with date-aware duplicate comparison #2236
Description
Is your feature request related to a problem? Please describe.
I use QuickAdd to record habit completions in a note's complete_instances list. Each completion adds today's date in YYYY-MM-DD format
Property Capture now handles most of this, but I still need a user script to keep the list sorted. This matters when dates are entered out of order or an earlier completion is added later. My script also compares existing non-string date values as calendar dates before deciding whether today is already present.
I'd like to configure this in QuickAdd instead of maintaining a separate script. Sorting would also be useful for other list properties, independently of the date-handling part of this request.
Describe the solution you'd like
Two optional capabilities for captures that write to list properties:
- Sort the resulting list
preserve existing order by default, with opt-in ascending and descending sorting. Text sorting would cover consistently formattedYYYY-MM-DDdates as well as ordinary text lists. Apply sorting after combining the existing and captured items and removing duplicates for both Add to list and Set value. - Compare date entries consistently
an explicit date-list mode that can recognize supported representations of the same calendar date when checking for duplicates, separate from ordinary text deduplication
adding 2026-10-11 to list with ascending sorting enabled
complete_instances:
- "2026-10-10"
- "2026-10-12"would produce
complete_instances:
- "2026-10-10"
- "2026-10-11"
- "2026-10-12"Adding 2026-10-11 again would leave the values unchanged.
Describe alternatives you've considered
- Keep the current user script. It works, but duplicates behavior that otherwise fits property Capture.
- Use Add to list with
{{DATE:YYYY-MM-DD}}. This covers normal completions and duplicate avoidance, but does not keep out-of-order dates sorted. - Use
{{PROPERTY}}to place new values before or after existing ones. That controls insertion position, but does not determine where a date belongs within the list. - Put the sorting logic in an inline script using
propertyValueorlist. This avoids a separate file, but still leaves custom code to maintain. - Clean up existing date representations once and always append completions chronologically. This is sufficient for a simpler workflow, but does not handle later corrections or backfilled dates.
Additional context
Related work:
- #1756: Each line of a property capture value is its own list item provides multiline list handling and duplicate removal.
- #1762:
{{PROPERTY}}token for property Captures provides composition and insertion-order control. - #1365: Ordered section placement for reverse-chronological logs related sorting behavior for Markdown sections rather than property values.
I searched open and closed issues, pull requests, and discussions and did not find an exact request for property-list sorting with date-aware duplicate comparison.
Activity
feat(capture): sort list properties written by property Capture (#2237)
chhoumann commentedon Oct 13, 2026
Thanks for the detailed write-up. The example and the list of alternatives you tried made this easy to scope.
Sorting is in #2237 and will ship in the next release. Property Capture now has a Sort list setting with Keep order (the default), Ascending, and Descending. It sorts the whole list after the new items are merged in and duplicates are removed. It works the same for Add to list, for Set value on a list, and for formats that use
{{PROPERTY}}. Items sort in natural text order, soYYYY-MM-DDdates sort chronologically anditem 2comes beforeitem 10.For your habit note, this setup replaces the script:
complete_instances{{DATE:YYYY-MM-DD}}Adding
2026-10-11to2026-10-10, 2026-10-12puts it in the middle, and adding it again leaves the note unchanged. For backfills, use{{VDATE:date,YYYY-MM-DD}}as the format. It asks for a date (yesterdayworks) and always writes it asYYYY-MM-DD, so it sorts into the right place.I decided not to add the date-aware duplicate comparison. Obsidian reads an unquoted date in a property as text:
- 2026-10-10comes back as"2026-10-10", the same as the quoted form. So the non-string date values your script handles never reach QuickAdd. What remains is one date written in different ways, such as2026-10-11and2026-10-11T08:00. Treating those as one item would need a separate date mode, format guessing, and a rule for which spelling to keep. A single{{DATE:YYYY-MM-DD}}format never creates that data. A one-time cleanup of the existing entries, as you suggested, covers the rest.Docs: https://quickadd.obsidian.guide/docs/Choices/CaptureChoice/#property