Command nodes help you get one or more tasks done in Tana. You can create your own command nodes with multiple commands, or steps, within them. For example, build a “Process voice memo” command node that grabs the voice recording, transcribes it, creates and tags tasks and ideas that it finds, and sends it all to your daily notes.
Command nodes can be run via the command line, as buttons on a supertag, or via node events.
Command nodes are easier to understand if you're already comfortable with using the command line and the search query.
There are three essential elements to creating custom commands: the command node that is a container for the command, the commands that represent the actions you want to do, and the parameters that are the settings for the commands
To create a custom command node, run Cmd/Ctrl+K > Convert to command node on an empty node.
To configure what the command node does, add commands as child nodes to it. To get a list of all available commands you can add, use @.
Each command can receive certain parameters (represented as system fields), listed in the description. The ones that are starred are required. Add the necessary parameter fields to the command (hit > to create a field, then the name of the parameter), and fill it with the necessary field value.
If there are multiple commands in the command node, they are executed in the order that they're listed from the top.
You cannot add the same command twice. To repeat a command, wrap it in another command node and add that to the list.
Command nodes appear as buttons attached to nodes, supertag instances, or fields. They also appear in the command line.
You can control when/where a command appears by using node filter and node context parameters on the main command node.
You can find all commands in your workspaces by writing the keyword operator IS COMMAND in the search node.
To configure the command node, select the commands you want using @. This gives you a filtered list of all available commands, including Tana commands, AI commands and custom commands you've defined previously.
Tana commands include:
Set field value tells the system to do the _action_ of setting a field underneath your node—same way we do it ourselves—and then, optionally, filling that field with a specific value.
Insert a cloned copy of a node tells the system to do the action of copying another node (that you specify inside the command) and bringing a clone of that node into the context in which you're working.
Add tag adds a tag to your node, and Remove tag takes one away.
Each command has a set of parameters you use to configure it. To add a parameter to a command, add any of the listed parameters as a field under the command. Parameters with a star are required.
Using the example of the Move node command, you'll find these settings:
Target node: Let's you instruct the action where to send the moved node.
Remove reference after moving node: Let's you decide whether you want there to be a reference to your moved node at the current location, or not.
Node filter/Node context: These settings are available on all commands and let you specify which nodes will run your command, in various ways.
Using the Move node-command and these settings, you could, for instance, make a command that
Sends a node to your team workspace and
Removes the reference from your workspace
Combining this with Add tag and Set field values, you could
create a new #project (Add tag)
assign it to your teammate Brage (Set field value)
set status to Active (Set field value) and
send it to your shared workspace Viral Content (Move node)
Once you've configured your command node, it will appear in the command line (Cmd/Ctrl+K) as another command you can access alongside the default commands.
Once you've configured your command node, you can use it to make buttons appear in any node. With your caret on target node, go to the command line Cmd/Ctrl+K > Configure node to open the node configuration. Add your command node in the Commands field.
You can also add a command node to a supertag or field, see the Advanced section of the supertag/field configuration panel. The command will appear alongside the tagged node or field.
You can find all commands in your workspaces by creating a search node and using the keyword operator IS COMMAND. Scope it down to a workspace to only find commands from there.
Takes the same information that is stored as a custom view on a node - can be used to configure which columns are shown, sorting, filtering, grouping etc.
Let's you run a command on the children based on what currently is in view. It respects the current search query (which may not be saved) and filtering of results.
Description: References to other fields on the same node. If any of these fields are empty, and have AI turned on, then their AI prompts will be run before evaluating this command.
Description: Write out the commands you want to run.
If you're uncertain about how a command is written out, navigate to it through the command line, create a custom shortcut, and go to Settings > Private keyboard shortcuts to the shortcut you just made and expand it. You'll find the command written out in a node.
Description: Either a date, or use Lookup field to reference a field. If reference date is May 1, and relative date is in two weeks, the output will be May 15th.
Description: Allows you to specify the granularity of the date object. Use the dropdown to set year, month, week, day, hour, minute, second, or millisecond.
FixedFixed bug where Fetch Youtube Transcript command node was not working. ()
ImprovedUnified the implementation of the command nodes "Set field values" and "Set field values for all children", adding the "Append" parameter to "Set field values for all children" as well, and fixing a bug where it did not work with an empty field value. ()
ImprovedInsert relative date now supports system date fields in the prompt, such as ${sys:dateFromDayNode} ()
ImprovedSlash in the beginning of node filter no longer triggers the slash menu (making it easier to enter a regular expression) ()
ImprovedAny fields inserted from command nodes, which are optional fields, will now be inserted at top of the node. ()
There is a command called Set view definition. It can set the Group, Sort and Display settings of a node view.
There is no good UX for this at the moment, so the instructions are not conventional nor friendly for beginners. But right now, this is one way of doing it:
Mock up a node that will have sample child nodes representing the data you'll be applying this command on
Then, create the exact view settings you want with Group, Sort and Display.
Go Cmd/Ctrl+K > Debug Node on the parent node and look at Views for node:
Clone the fields over to the command node so it looks like this:
When you run this command on a node, this should change the view settings according to your configuration.
How can I add supertags on things that I send from Tana Capture?
Sep 26, 2024
While it isn't possible to tag things when you're sending things from Tana Capture, you can have Tana do some post-processing magic to convert written-out tags to real tags once they arrive the Inbox—no AI needed!
This method uses a simple Tana Paste command that you can run on the Inbox node, which targets all new children that have "#" in them.
Once you've created the command, you must add it to the On child added section of the Inbox node. You can find it by running the command Debug node on the title of the Inbox.
"All it does is paste the nodes that have # in them and that are not tagged, using Tana Paste.
Say we add this through Tana Capture:
buy milk #todo
The command will paste that exact text back in with Tana Paste, where ${name} is buy milk #todo and ${sys:content} are any child notes that are present. Using Tana Paste, #todo will be added as a tag.
Note: this creates a new node, so the created date will change, meaning you’ll lose the time that the node was captured through Tana Capture."
How do I share a supertag from my private workspace to a shared one?
Sep 26, 2024
Currently, the easiest and most foolproof way to do this is to not share it but instead build the supertag, with its fields and anything else necessary for the supertag to work, from the ground up in the new space.
That said, if you still want to move a supertag over that exists only in your private workspace, the main work is to ensure that there's nothing in the supertag that references something in your private workspace, otherwise it will appear as broken to others once it's moved.
It's like packaging up a zip file. You can't just zip up a bunch of shortcuts, you need the real files in there or the recipient will only see broken shortcuts.
You'll also have to remember to move over other things like field options, commands, and ensure that no saved view options contain elements from your workspace. Basically, you must ensure that nothing you're moving over from your workspace contains references from your workspace.
To bring all nodes (except system nodes) into the supertags, fields and commands you want to move, use the command "Bring referenced node here". Alternatively, you can move each necessary node separately too if you for example want the field definition to exist outside the supertag. But the key is that everything that is connected to what you're sending over gets sent over too, otherwise there will be missing pieces.
Can a command move the current node to a field of a new node?
Sep 26, 2024
Yes, you can. Make a new command node, and use the command Insert Tana Paste with the following prompt:
- ${name} #note - Based on:: [[^${sys:nodeId}]]
The first line is the new node. It uses the name of the current node to inform the name of the new node by using the title expression ${name}. The supertag #note can be enough for Tana to find the right tag to use, but you can specify it more precisely by adding the ^nodeID to it. See the Tana Paste doc for more info on this convention. To retrieve the nodeID of a supertag, run the command Copy link (HTML formatted) on a supertag definition and paste the results. It will paste with the nodeID written out:
The second line is the field. After the name of the field and the double-colon :: is a reference to the current node that the command is being run on, which it is able to target by retrieving the nodeID of the current node using the title expression ${sys:nodeId}.
This is what the command node should look like:
Special thanks to Navigator Emmanuel Galanos for this clever solution!