Very small feature request: Placeholder for "Parent group name"

The request
If it’s easy to implement :grinning: could we please have a Placeholder for Parent Group Name?

The reason
I have a number of smart rules which file items automatically categroised by year within groups called, for example, “Paid on-line bills”, “Bank Statements”, etc. Existing Placeholders which could be used for the relevant notification following filing are Group Name and Top Group Name. However, Group Name gives me a notification, for example, “Filed in 2020” (which is not really useful) and Top Group Name is not relevant.

Obviously it’s perfectly easy for me to write the notifications manually, without the Placeholder, but I suspect there could be other uses, in circumstances similar to this, for a Parent Group Name Placeholder.

I do emphasise this is a very small feature request and, of course, shan’t be at all concerned if it can’t be implemented for any reason!

Stephen

Actually Group Name should return the name of the enclosing/parent group. A screenshot of the hierarchy would be useful.

Thanks for the quick response.

Here is an example of the hierarchy:

Hierarchy

Here is the smart rule (part obscured) which seems to result in the notification “Filed by year in Personal > 2020”:

Rule

Stephen

This seems to be correct, the name of the database is Personal and the group is 2020. But you want to use Bank statements instead, right?

Yes—that’s what I’d like to do ideally.

Stephen

Just wondering how such a placeholder should be called as both parent group name and enclosing group name are not really obvious (2020 is the parent/enclosing group in your example). At least from my point of view as a non-native speaker :smiley:

Yes—it’s tricky. If you wanted to follow the “parent” analogy I guess you could refer to Grandparent Group. :wink:

We currently have simply Group Name—which presumably should not be changed so that it always points to the current (or enclosing) group. In that context I felt Parent Group might be sufficiently clear as pointing to one level higher in the hierarchy. (In other words, with the two placeholders it would be clear that Parent Group is something different from Group Name.)

I am a native English speaker so maybe my thinking simply demonstrates the challenging nature of your comment! It would be interesting to hear the views of others.

Stephen

In Stephen’s example to me as a native speaker 2020 is the group, Bank statements is the parent (of the) group and Personal is the database. 2020 is the child group of Bank statements - the operative word is group. The contents of 2020 are the children of 2020. I admit, however, that confusion is possible - as using script, 2020 would be the parent, and its contents would be the children. I feel that using parent of group vs parent could be the solution.

Criss, I think you may be looking at this not only as a non-native speaker (your English is not exactly bad, mate*) but also as a programmer: DT uses the term record to cover an entry in the database, i.e. both for documents and for groups. If you treat a group as a record, then the nomenclature must be as you say: 2020 is the parent of the contents of that record (group). Whilst that may be true for the internal workings of DT, I’m not sure it is relevant to the average** user. The only qualm I would have would be the discrepancy in the use of terms between smart rules and scripting (which I would circumnavigate by using the terms parent (the next record up) and parent of group (the next group up).

* just in case you are not versed in the peculiarities of the English language: das heißt dein Englisch ist echt ziemlich verdammt gut (see this chart for an initial guide on what we mean when we say …)
** Stephen, I am not calling you average here :stuck_out_tongue_winking_eye:

I can’t deny that :slight_smile:

Thanks! :blush:

So Name of parent of group would be obvious & precise but definitely cumbersome. That might work at least in case of English. Except that for the German or French translation an easier expression would be preferable. Or maybe I just need more coffee :open_mouth:

@Blanc I was hoping you would contribute: I value your contributions on this forum (and didn’t necessarily think you intended to imply I was “average” :wink:).

I think your idea of Parent of Group is good—because it clearly implies the link to the existing Group Name and at the same time indicates something higher up the hierarchy (at least to me!).

So Name of parent of group would be obvious & precise but definitely cumbersome. That might work at least in case of English.

While I’m getting completely lost in the tangle between liguistics and programming I suppose you could shorten that to Parent of Group Name—but then there would be minor confusion as to whether “Name” governs “Group” or “Parent of Group”. Alternatively, Name of Group Parent would probably work.

<Sigh> I shall never again call anything a “Very small feature request”: sorry!

Stephen

Maybe the easiest solution is to use a slightly different notification:

Or a script:

on performSmartRule(theRecords)
	tell application id "DNtp"
		repeat with theRecord in theRecords
			display notification "File by year in " & (name of database of theRecord) & " > " & (name of parent 1 of parent 1 of theRecord)
		end repeat
	end tell
end performSmartRule

The script seems to work for the first Group (as shown in the hierarchy in my initial post) but for three other groups (lower down, and one nested further into, the hierarchy) for some mysterious reason gives me the notification “Filed by year in Personal > Tags” (which is a group which does not specifically appear in that database). However, subject to that, Location would be an excellent placeholder to have.

I’m sorry all of this is so much of a pain! It certainly does highlight again my woeful lack of knowledge of AppleScript.

Stephen

Well, in DEVONthink groups are tags and tags are groups. And tagging is replicating and vice versa. Basically the same things, just from a different user perspective and for a different workflow. Therefore a more advanced script would have to ignore parents which are ordinary tags.

This placeholder exists already.

Thanks for the explanation, which I understand. No doubt I could relatively simply ensure that the Hazel Blue tag is automatically removed on import for the relevant files but I’ve come to the conclusion it’s really much simpler to write manually the path for the notification in each smart rule.

I’m sorry for the rather more complex diversion than I’d anticipated when I first posted. There are clearly times when the simplest solution is the best—even if not the most flexible.

Edit: Apologies for overlooking the Location placeholder. However, that still gives me the tag problem so I’ll do as I’ve said!

Stephen

To add one more post… I’ve simply amended the relevant smart rules to include deletion of all tags on import and “Filed by year in Database Name > Location” works fine as a notification. Thanks for the tips.

Stephen