Skip to content

feat: date tokens in Move/Copy destination paths - #80

Merged
lguichard merged 2 commits into
lab421:mainfrom
prismatic7:feat/date-token-destinations
Oct 24, 2026
Merged

lguichard merged 2 commits into
lab421:mainfrom
prismatic7:feat/date-token-destinations

Conversation

@prismatic7

Copy link
Copy Markdown
Contributor

Closes #34. Also answers the follow-up requests in that thread (~/Screenshots/{year}/{month}), and it's the first item under "Dynamic destination folders with date tokens" on the README roadmap.

What

Move to folder and Copy to folder destinations now accept {year}, {month}, and {day} tokens, expanded per file before the move/copy — so a monthly-download-archive rule is just a destination like ~/Downloads/Backup/{year}-{month}.

  • Month/day are zero-padded (07, 05); unknown {...} sequences are left untouched, so a folder legitimately named Keep {literal} still works alongside tokens.
  • Date basis: the file's creation date (falling back to modification date, then now). For the workflows in the issue — downloads, screenshots, AirDrop arrivals — creation date is the "when did this file appear" date the tokens should express. Flagging this explicitly as the one design decision a maintainer may want to weigh in on: an alternative is Finder's "date added" (which tracks arrival in the watched folder rather than creation), at the cost of a Spotlight metadata query per file.
  • Tokens are expanded in both the Dry Run plan and execution (all four destination read sites), so previews show the real resolved path and the Already in destination no-op check compares against the resolved folder.
  • Nested tokened folders are created as needed (moveIntoDir already creates intermediates).
  • The destination field is now an editable text field with the same styling and an unchanged Choose… button — the exact pattern AppPickerField/ApplicationPathPickerField already use ("stays a plain text field underneath so … can still be typed manually"). Without this, a tokened path could not be entered at all, since the field was picker-only.

Three-path consistency (per AGENTS.md)

Expansion happens where the destination param is read, shared by Dry Run planning and execution; the watcher path runs through the same plan()/execute() machinery. No path-specific code touched.

Verification

  • swift build clean.
  • swift test: 332 tests in 28 suites, all passed (329 existing + 3 new).
  • New tests: move with {year}/{month}-{day} (plan + execute against a fixed creation date), copy with {year}/{month} (source kept), unknown-brace destination left alone.
  • Left to CI: the editable FolderField rendering; no GUI run locally.

prismatic7 and others added 2 commits October 24, 2026 02:14
Adds {year}, {month}, and {day} tokens (month/day zero-padded) to the
destination of Move to folder and Copy to folder, resolved from each
file's creation date (falling back to modification date), so workflows
like ~/Archive/{year}/{month} need no script. Unknown {...} sequences
are left as-is. Tokens are expanded in both the Dry Run plan and
execution, so previews show the real resolved path and the
already-in-destination no-op compares against it.

The destination field becomes an editable text field (same pattern as
the app path pickers) so a tokened path can be typed; the Choose…
button is unchanged.

Closes lab421#34
@lguichard

Copy link
Copy Markdown
Collaborator

@prismatic7 Thanks ! I added a small helper

@lguichard
lguichard merged commit 055cefa into lab421:main Oct 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Feature Request: Dynamic date placeholders for destination paths (e.g., YYYY-MM)

2 participants