DR3 Pro - Global vs. 'local' inboxes

Don’t get me wrong. DT3 is great and an improvement over DT2. My criticism of the collection of inboxes and tags in the sidebar is not an example of me being a curmudgeon who thinks the old is better than the new. Quite the opposite. I’m first on board when it comes to upgrading and adopting new versions. I’m expressing my perspective that, after extensive use of DT3, this particular change is not a good one. It interrupts workflows and breaks the logical sequestration of data between databases. Here’s a good example:

My typical routine is to open a database, view what’s in the inbox, and move files from the inbox to groups/tags inside that database. Sometimes I like to drag and drop. To accomplish that in DT3, I now have to find the Inbox I want and open it. I then have to go look for the corresponding database in the sidebar and open that, too, to see the corresponding groups. And if I want to see tags, I have to do it a third time. So it now takes me three steps to do what took one in DT2. And I have to repeat for every database. That requires a lot of extra effort and mental overhead. It’s a hindrance, not a help.

But more to the point: I’m not asking for you all to get rid of the new sidebar consolidation and return to displaying local inboxes and tags inside their respective databases only. I’m asking for you to provide both or to give users the option to decide which one they prefer. I’m sure there may be others who have different workflows who prefer the new consolidated sidebar. Why not let us decide what works better for our workflows?


Just curious, have u tried disable the option 23 and keep the inboxes expand at all time? I find this an easier way to access the inboxes.

Yup, I thinking it’s just getting used to it and finding the right “groove”

Yes, I have, but it doesn’t really address the problem I’ve described.

Disjointed databases, inboxes, and tags make it impossible to “see” an entire database in one consolidated view without expending additional mental effort to expand the right sections in the sidebar. I can’t just click on Database A and get a quick overview of what’s in it. Want to switch from a full picture of Database A and get a full picture of Database B? Gotta collapse three trees and expand three more. God help you if you jump between multiple databases multiple times every day.

If you segment data between databases (that’s the point of separate databases), you’re also increasing the odds of cross-contamination. When moving documents from an inbox into a group in the same database, you better make sure you expand the right database to keep things consistent. Get it wrong and your file is going to the wrong place. You don’t have to worry about that happening when the inbox and tags are in the right database to begin with. Simply select your database in the sidebar, hide the sidebar (if you want), and voila, everything you see from that point forward is for one database and one database only.


Further to this.

I have a whole bunch of recipe items in my Globals->Inboxes->Recipes and I have a database called ‘Recipes’. This database contains no folders, beyond the smart folders.

I want to categorise the Inboxes items into folders.

Looking at the first recipe in the Inbox I note it is a dessert. So I click on my recipe database and select ‘New Group’, intending to name it ‘Desserts’.

When I do this it closes (collapses) the Global->Inboxes tree. Now I have to reopen the Global->Inboxes->Recipes tree again to find the item and drag across to my newly created Group.

If I want to scan the inbox list as a whole to determine and create Group categories holistically, I can’t, as it will close the inbox when I create each Group.

Not sure if this is a bug or a feature.


Sounds like a bug but I can’t reproduce it with the current internal beta I’m running. If you want to post a screencast here, or just stay tuned for the next beta release…

Regarding this point:

Is there a reason why we can’t slow double click to rename in the Navigate sidebar? Especially since now this is the main place where I am interacting with many groups and I frequently need to rename them. Slow double click doesn’t seem to be doing anything else. I don’t see why it can’t behave the same way as the item list view. I’m wondering if there is some logic behind it that I am not seeing. Is there a way to choose this as an option? It would be a big help.


Development would have to respond on this.

My two cents: I like having the Inboxes collected in Globals, but I’d also like to see the Inbox for each database in its database. I don’t see what’s gained by only providing the first option, and not the second.

Doesn’t look like I can upload *.mov files.


I am just “guessing” here, but there could be a work around to both see and open a database-specific inbox within the database even under the current setup:

To see what’s inside the inbox: Just create a local smart group with the search scope set to the inbox.
To open and manipulate the content of the inbox within the database: attach a trigger script to the smart group so that the current main window will jump to the designated inbox when the smart group is being clicked or opened. I guess someone will be able to help in that script?

With this setup, the inbox content can be viewed right inside the database as a group, and be opened and manipulated as if it is a local group in the database?

I have actually gone through two stages of workaround.

I started with just creating a new group called ‘Inbox’ at the top level of the database, then moving everything from Global->Inboxes->[DB Inbox] to this new group.

This at least saved having to scroll up and down the tree list. While this was fine for dragging out items from my new inbox group to other groups, to sort things, this only really works when the target groups have already been created. Creating a New Group to categorise something deselects my ‘Inbox’ group, so creating a bunch of new groups this way doesn’t really work.

What I now do is just drag the contents of Globals->Inboxes->[DB Inbox] to the top level of the related DB.

Then in the right pane I can see all the items formally in the inbox, plus I can right click and create groups in there, without it closing the top level list.

I’m basically no longer using inboxes at all. When I clip from somewhere I just put the item in the top level of the database and it is in bold when I latter look in there, so easy enough to see what is new.


You can just create a smart group that shows all the contents of the database’s inbox.


The limitations of this are:

  • you cannot drag files into a smart group
  • a smart group cannot be unsorted (which is my default way to work).

Is there an easy way to recreate this behavior using a keyboard shortcut instead of a slow double click or would I need to write a short applescript to do that?

Sorry, but there are no keyboard shortcuts for this. Development would have to assess the behavior here.

The next beta will revise this, a click on the name of an already selected item will start renaming (just like in views).

The usability regression is paralyzing.
I can not believe what I’m seeing to be honest…

A database was a microcosm unto itself, a self contained unit, now a single database is split in three, in three different windows.

When I click on database X.
I want to see database X’s inbox, tags and contents in the SAME place in the SAME window. (Like how it used to be)

Instead of having to scroll my entire tree of databases and click into three separate windows.
Also because each window only shows either inbox items, tags or database contents it’s as if the data is practically in different locations all together. This makes working with the data an exercise in misery.

Not being able to see all of the data for one database in one place is a monumental UI and UX failure.

This software was created to provide an indiviual with a way to seamlessly manage information, how in the name of sin does this change, this implementation, assist with that goal in any, way shape or form ? All this does is cause dissonance.

I resoundingly concur. As you stated Daniel “Unequivocally more cumbersome”

Why can’t we simply have the choice?

For those who want Inboxes and tags outside of the database, they can have that and for those that want the original format, inboxes and tags within the database they can choose that in preferences.


It’s only a workaround, but you could try this triggered script. It will update the tags group of your database in the database tree when clicked.

Copy the UUID of the top level tags group of the database and set this and the database name in the script. Create a group in your database, e.g. “Tags”. Attach the script to this group.

I don’t use tags, but from a quick test it should be possible to delete the newly created group (manually) without deleting the real tags. This way you can see which replicants are “real” and not due to this workaround. Try it with a test database first. If you want to delete your fake tags group when not needed use the second script, create a helper group to which you attach this script and set the name of the group (not the name of the helper group) which should hold your tags in the database. This group will be created by the script if it doesn’t exist so just choose a name.

-- Workaround: Replicate tags into the database tree
-- Create a new group in your database and attach this script. It will update your tags when clicked

property tagsUUID : "" -- UUID of your database's top level tags group
property theDatabaseName : ""

on triggered(theRecord)
	tell application id "DNtp"
			set theTagsGroup to (get record with uuid tagsUUID)
			set theTags to every child of theTagsGroup
			repeat with thisTag in theTags
				replicate record thisTag to theRecord
			end repeat
		on error error_message number error_number
			if the error_number is not -128 then display alert "DEVONthink" message error_message as warning
		end try
	end tell
end triggered

Attach this to a helper group if you want to delete the fake group when not needed:

-- Workaround: Replicate tags into the database tree
-- Create a helper group in your database and attach this script. It will create another group which holds replicants of your tags and it will update your tags when you click the helper group.
-- If you want to update your tags without clicking the helper group attach the trigger script to the fake tags group, in this case you would only need the helper group to create the fake tags group once or if you deleted the fake tags group

property tagsUUID : "" -- UUID of your database's top level tags group
property theDatabaseName : ""
#property triggerScriptPath : ""

tell application id "DNtp"
		set theDatabase to database named theDatabaseName
		set theGroup to create location "/.WORKAROUND TAGS/" in theDatabase
		#set attached script of theGroup to triggerScriptPath
		set theTagsGroup to (get record with uuid tagsUUID)
		set theTags to every child of theTagsGroup
		repeat with thisTag in theTags
			replicate record thisTag to theGroup
		end repeat
	on error error_message number error_number
		if the error_number is not -128 then display alert "DEVONthink" message error_message as warning
	end try
end tell

If you want to use a database’s inbox in the database tree of the sidebar see this thread

Hey Sam

I’m totally with you on this. So… Create a Group in each database called “An Inbox” (to ensure it’s at the top of the DB tree), then create separate smart rules for each of the Globals Inboxes, that automatically move all content to the new Database Group Inboxes. A similar proces could be done with tags too.

(In the smart rule, set it to <perform the following actions: ‘On Moving Into Database’>)