Creating embedded base for files modified in the last 7 days

Help
1

What I’m trying to do

Working on my weekly review note processing. I already have a base that tells me what notes have been created this week. I do my reviews on Sunday, so it looks back to notes created the previous Sunday to Saturday. The notes created base looks like this and works fine:

filters: file.ctime.date() >= this["date created"].date() - "7 days" && file.ctime.date() < this["date created"].date()
views:
  - type: table
    name: Last Week's Notes
    order:
      - file.name
      - file.folder
      - file.ctime
    sort:
      - property: file.ctime
        direction: ASC
    columnSize:
      file.name: 204
      file.folder: 195

I want one that looks for any files that were:

  1. modified this week based on a user-defined property (ie, modified date, it has the date and time based on 24-hr, but the time should/can be ignored.)
  2. excludes any of the files that were created this week (they are already in the other base, which is hard-coded with the date for future-proofing and record.)

I know the modified property is dynamic and will change as notes are updated. I just need it for the review when I do it.

Things I have tried

I’ve tried several iterations myself, and I’ve tried some AI assistance to no avail. I struggle to understand the logic of the bases, and the documentation escapes me.

I found this forum thread, but I don’t understand what they did to replicate it myself. Or even if it works for my situation.

1 Like
2

Give this base a try:

filters:
  and:
    - note["modified date"].date() >= this["date created"].date() - "7 days"
    - note["modified date"].date() < this["date created"].date()
    - or:
        - file.ctime.date() < this["date created"].date() - "7 days"
        - file.ctime.date() >= this["date created"].date()
views:
  - type: table
    name: Last Week's Edits
    order:
      - file.name
      - file.ctime
      - modified date
    sort:
      - property: modified date
        direction: ASC

There are multiple ways to go about grouping the filters for your base. The base above does:

  • must have been modified within the week (the first two filters)
  • must have been created either before this week or after this week (the two filters in the “or”)—hence not created this week
2 Likes
3

This is GREAT! Thank you.

I do have one question. The base appears to be tracking both dates and times. So if the base is created at noon today, it won’t include any notes made before noon 7 days before.

Is there a way to force the base to only consider the date, regardless of the time that a note was made on that day?

How can I make this “templateable”? It will be going in my weekly review note template.

Also, as an aside, is there some special spacing convention we need to follow when typing out an embedded base? When I copied your code, it worked fine. But when I tried to do it myself, my tabs weren’t right, and it was a mess. :rofl:

4

Appending .date() to all of the datetimes should already be taking care of that.

How can I make this “templateable”?

Once you’ve created this base as, say, “weekly review.base”, you could embed the base file in your template like this:

![[weekly review.base]]

When you use that template to create a weekly note, the base will automatically appear there, and it will inherently use that note’s date created property.

The benefit of this method is that if you ever want to change something about the base in every weekly note, you need update the base in only one place.

But if that’s actually a con instead of pro in your workflow, then you could instead embed the base code block into your template, like:

```base
views:
  - type: table
    name: Table

## Include your base's full code.

```

That puts an independent base in every weekly note.

is there some special spacing convention

It’s pretty much two spaces for every indentation level. Tabs aren’t accepted.

I think everyone has just been sussing out the syntax from both Bases syntax - Obsidian Help and the code that gets created when you use the interface.

6

I wrote it for the OP’s scenario. You would need a property named date created in the active note. The value of date created and the file’s ctime would have to be in the respective ranges.

1 Like
7

What if I would like to filter for file.ctime.date() >= this.file.name - “7 days” (provided that the filename is formated like YYYY-MM-DD)?

8

Give this a try:

file.ctime.date() >= date(this.file.name) - "7 days"
9

I went back and looked. While experimenting I had somehow removed some of them. It should be good now.

Also, thank you for the clarification for the base formatting. I could not figure that out!!! :man_facepalming:

10

@dawni

I’m getting this error now: Failed to evaluate a filter: Cannot find function "date" on type String

I’m not sure why. I’m seeing it in my ipad app.

11

If the base is unmodified from how I posted it, the error is likely from having modified date or this’s date created values that are not in an accepted date format.

The easiest first thing to check is the current weekly note’s date created. Clear its value then use the date picker to reenter it. If the error goes away, yay, you found it quickly. But if the error persists then…

You could validate you modified date values by creating a new base with this filter:

'!date(note["modified date"]).isType("date") && note["modified date"]'

That’s how the filter is typed in the code. If you instead use the interface to enter that filter, then remove the single quotation mark at the beginning and end.

For any notes that show up in this new base, view the note in Source mode to confirm that the property value is a valid date format. If you can’t tell or even just want a way to correct them without typing, then in Reading/Live Preview, clear the date and reenter it using the date picker. Having the correct format should remove the note from the new base (and remove one source of the error). You would have to clean up all such notes.

And if the error persist and you’ve changed the base in a way that applies .date() to other properties, check those properties too.