This script will export a selected group and its children. It will then index that exported group. The process can be used to convert a group that is internal to the database into an indexed group.
Why would you want to do this? It is helpful when rearranging documents or group hierarchies in the the database. If you have a collection of groups and files some of which are indexed and some are not, and you want to reorganize, a helpful method is to move everything into the database with the “Move into Database” command, then do your housekeeping, and then use this script to put the new hierarchy back to disk and index that hierarchy back to DEVONthink.
To use this:
- Select a group – a group with child groups is OK
- Run the script
- You will be prompted for a file system destination for that hierarchy of group(s) and files
- The script will export the hierarchy to that location
- You will next be prompted to choose which parent to index
- That folder and its children will be indexed at a location in your database that has the same parent as the group you chose in step 1 – the reason for this is that the indexed group will then be a sibling of the group selected in step 1
The group selected in step 1 and the indexed folder resulting from step 6 are identical – one hierarchy is in the database and one is hierarchy is external and indexed. The group from step 1 is usually left in place and not deleted. However, there is property at the head of the script “deleteOrMove” which can be set to “true” (the default is “false”). If that property is true then a feature is activated that opens a dialog asking if you want to delete or move the original step 1 group. If you choose to move that group, you are prompted for a destination in any of your open databases. This latter feature can be helpful if you are reorganizing your data among different databases.
You will notice copies of a file “DEVONtech_storage” that appear in folders that contain data exported from DEVONthink. These contain metadata that DEVONthink is interested in – though not used or useful in the case of this script. The script does not delete these files, because they belong to you, but it is safe to delete them if you choose.
[size=85]Before using this script on a group, I recommend manually turning off group-tagging for the group and for its child groups. Select the group and make sure “Exclude from Tagging” is checked. This step will avoid a possible issue with Mavericks tagging. After you finish converting a group to an indexed group you can restore group tagging if you wish. I might update the script in the future to automate this precaution.[/size]
(* 20131122.2*)
property deleteOrMove : false
tell application id "com.devon-technologies.thinkpro2"
try
set theSelection to the first item of (selection as list)
if the kind of theSelection is not "Group" then error "Please select a group"
set theParent to the first parent of theSelection
set theChildren to (every child of theSelection) as list
set x to choose folder with prompt "Select a folder"
export record theSelection to x
set x to choose folder with prompt "Choose parent folder to index" default location x
indicate x to theParent
if deleteOrMove then
set theName to the name of theSelection
set theQuestion to "Delete or move the original (non-indexed) group at" & return & theName
set theAnswer to button returned of (display dialog theQuestion buttons {"Delete Original", "Move Original", "Cancel"} default button 3 cancel button 3 with title "Delete or Move?")
if theAnswer is "Delete Original" then
set theResult to delete record theSelection
else if theAnswer is "Move Original" then
set theResult to move record theSelection to display group selector
else
return
end if
end if
on error error_message number error_number
if the error_number is not -128 then display alert "DEVONthink Pro" message error_message as warning
end try
end tell
[size=80]There was a request downstream in this thread to include logic to optionally replace the external folder if it existed before this script was run. I’ve examined the logic to support this and concluded that there would be too many alternatives to make this a stable and understandable processes. Just a simple example: what if there are more than one group in (one or more databases) with the same name or the same content? Then what is being replaced? How to know? I think this is computationally intractable, but would welcome suggestions. [/size]
