Hello. I have a couple of smart groups set up that looks for items with a tag within specific folders/groups of my database. However, they’re not working. They’ve been set up for a few months, but I don’t look in them much so I don’t know if they did work and have stopped, or if they never worked and I didn’t notice.
The rule should be:
Item is in XX folder
Item has YY tag
Useful info:
The items are in subgroups, so none of the files that should be identified will be in the “title folder”. However I haven’t ticked the box to exclude subgroups, so I don’t think that’s the problem?
The items won’t only have this tag. I assumed the rule is looking for the occurrence of this specific tag, and isn’t excluding any situations where an item has more than one tag, is that right?
Any idea what might be the problem? I know lots of items meet this criteria.
I have more groups to set up, but I don’t want to do it until I’ve figured out where I’ve gone wrong with these.
Does that mean “the item is in folder x and has tag x” (x being the same both times?) or “the item is in folder x or it has tag x” (again: x being the same in both cases), where “or” is exlusive or inclusive?
Firstly, search is looking at the emojis in the tags, i.e. it is not only searching for the alphanumeric characters but the entire tag.
Secondly, I actually altered the name of that tag slightly a few weeks ago, and the rule in the smart group did not update to the new name. I don’t know if it was meant to, but since it was that specific tag that was updated, I would perhaps have expected any occurrences of that tag in smart rules or smart groups to update too?
How would you envisage the smart rule doing that? If I change my tags “a” to “b”, why would smart rules referring to tag “a” change automagically to tag “b”?
Why, oh why? Imagine I want to find all records with tag “a”, so I set up a smart group to do just that. Now I change that tag to “b”, because I don’t want “a” any longer. Now my smart group that I explicitly told to show me all records with a tag “a” suddenly shows a lot of records, but I’m sure that I changed “a” to “b” already… Confusing, at best (but a good way to generate lots of interesting posts here).
Let’s just expand on the idea: I set up a group for all records whose extension is “.txt”. Now I decide to modify some of these records so that there extension is “.md”. What should the group do - change its condition to “md”? Change it to “maybe md”?
No, smart groups and smart rules are static in the sense that their conditions and actions do not change just because you change some records. Just imagine, btw, you had removed all these tags – should the smart rule have disappeared into thin air, too?
Fair enough. I’m used to the databases I work with updating all occurrences of the specific tag if the spelling is changed. In your scenario you would have to create a new tag called “b” and apply it to all items that have tag “a”, before removing tag “a”, if you didn’t want it to update all occurrences of “a”. But I understand why in DT’s ecosystem that would not be desirable. To be fair, it’s not necessarily always desirable in other software either, it’s just what I’m used to
Can I be cheeky and add a second question into this thread, as it fits under the same title and is still me trying to get to grips with smart groups (and failing).
I have set up a group with this rule:
My intention was to group items that have not been opened for a year, so that I can review them for retention/deletion (I lean towards unnecessary collection of files).
Now, in theory there should be nothing in this group, because I have not yet been using DT for a year. However, it is identifying some files. I have noticed that some are files created by other smart rules (that’s fine and it makes sense I think because the files have never been opened, so technically meet the rule’s requirements, is that right?). Other files are files I’ve created though, so they definitely have been open in the last 365 because I opened them to make them. Any idea what I did wrong here?
Not sure, but the solution would presumably be to add a “not created within the last 365 days” condition. I guess creating a file doesn’t count as opening it (makes sense to me, it wasn’t there to open as it was created…)
An interesting question with an interesting answer!
All the files have a “date opened” of 01/01/2001. By chance I’ve happened to spot a note I created last night on my iPad which now also has the same date opened.
It makes sense that the system treats “date created” and “date opened” as different entities, but I am a little confused as to why “date opened” can’t be set the first time as the date the file was created?
(I can’t use the “date modified” for my filter, as many of my files are just reference, so I may open them but not edit them.)
As far as I am concerned, because created != opened. The creation of a tin of baked beans is not equal to opening a tin of baked beans. I’m aware that analogy can be argued to be invalid - its only purpose is to represent my thinking. So whilst it’s clear to me that your thinking is different, changing the system would - in my mind - simply change the group of those confused or inconvenienced, rather than resolving a bug per se.
As I mentioned, you can circumvent the problem without difficulty simply by adding "not created within the last 365 days” to the conditions of your rule, keeping the All modifier.
Edit having written that, a simple/brief test shows that for documents literally created by me - that is, e.g. by selecting New > Plain Text - opened defaults to created; for items created by DT (e.g. a PDF of that plain text file, or an item sent via the inbox), opened defaults to DTday1. That is completely coherent behaviour as far as I am concerned.
I don’t think I’m reporting the same behaviour. If we ignore the PDFs in my example above (which entered via the Inbox and may or may not have then been manually OCR’d), you can see that there are various Markdown documents. All these files were created either within DTP or DTTG, and you can see they’re listing an open date of 01/01/2001, not the date they were created. (I don’t create any Markdown notes outside DT so these files were essentially “open” when I created them in DT.)
To be honest, I’m not sure it’s the ideal behaviour for email either. I don’t store many in DT so this isn’t a major issue for me, but to me it doesn’t make sense to have a “date opened” that pre-dates the sending of the email. I imported these emails via drag and drop though and I haven’t checked if the creation date is the date it was dropped in DT or the date of the actual email (I don’t really care, I’m just highlighting that it’s possibly a bit of weird open date value here).
Anyway I am going to apply the rule as you’ve outlined as this mostly serves my purpose. It actually doesn’t 100% solve the issue, because some PDFs are old documents with old creation dates (e.g. a 2013 paper), rather than the date they were imported into DT or downloaded by me. I generally ignore the creation date for PDFs because I’m aware that it’s not applied consistently in my files.
I can confirm that files I create in DTTG are shown with an Opened date 01.01.01 in DT. A quick test suggests that actively opening the file in DTTG does not change the Opened date in DT (tested with a simple .md file, obviously synced after viewing file). That to me is unexpected behaviour (@eboehnisch?)
01.01.01 is in lieu of no date at all
presumably no date would be a potentially invalid file attribute. DT uses the same default date for any custom metadata date field.
So use Date Added rather than Date Created? Only caveat: Date Added will change if you move an item from one database to another (so it’s the date the item was added to the respective database, rather than to DT).
Thank you, putting “date added” in the rule makes it work. I really appreciate your help
It does seem like “opened date” not syncing between DTTG and DTP might be an error, as it would be very useful for there to be parity here. I have realised following this thread that this is why the smart group that shows today’s activity in DTP is incorrect - because the opened date for files on DTTG is not syncing, so the smart group is only showing activity on the Mac. I will wait for @cgrunenberg’s comments on this.
