API Returns Only IDs for Existing Nodes Under Root Level

[sushmashetty305]

Description:
Nodes created via the API return full details and work as expected. However, for existing nodes (not created via the API), only their IDs are returned under the root level.

Steps to Reproduce:
Access nodes created via the API – returns complete details.
Access existing nodes (created elsewhere) – only IDs are returned.
Expected Behavior: API should return full details (e.g., title, structure) for all nodes under the root, regardless of creation source.

Example:
Use the following code to fetch and export a node's structure:

(async () => {
  try {
    // Fetch the Workflowy document
    const document = await workflowy.getDocument();

    // Define the ID of the node to export
    const nodeId = "xxxxxxxx"; // Replace with the actual node ID

    // Get the node by ID
    const nodeToExport = document.getList(nodeId);

    // Function to recursively collect text
    const exportText = (list, depth = 0) => {
      const indent = '  '.repeat(depth); // Indentation for hierarchical structure
      let text = `${indent}- ${list.name || "(Untitled)"}\n`;

      // Recursively append text for children
      if (list.items && Array.isArray(list.items)) {
        for (const child of list.items) {
          text += exportText(child, depth + 1);
        }
      }
      return text;
    };

    // Generate and print the exported text
    const exportedText = exportText(nodeToExport);
    console.log("Exported Text:\n");
    console.log(exportedText);

  } catch (error) {
    console.error("Error exporting text:", error.message);
    console.error(error.stack);
  }
})();

Expected Behavior: The code should retrieve and export the full hierarchical structure, including titles and other details, for all nodes.

Observed Behavior: For nodes created outside the API, only their IDs are retrieved, and their details (e.g., list.name) are missing.

Example Output:

All nodes under the root:
- Home (ID: None)
  - (Untitled) (ID: xxxxxxx)
  - (Untitled) (ID: xxxxxxx)
  - (Untitled) (ID: xxxxxxx)
  - Sushma Workflowy Created Test Node (ID: xxxxxxx)
    - Sub Point 1 (ID: xxxxxxx)
      - Updated Point 1 (ID: xxxxxxx)
      - Updated Point 2 (ID: xxxxxxx)
      - Updated Point 3 (ID: xxxxxxx)
    - Sub Point 2 (ID: xxxxxxx)
    - Sub Point 3 (ID: xxxxxxx)

Request: Please investigate why the API only returns IDs for existing nodes and ensure it retrieves full details for all nodes, regardless of their creation source.

[karelklima]

Hi @sushmashetty305,

Thank you for this issue.

I have tried to run the exact code you posted on my Workflowy instance and I got this result:

Exported Text:

- Home
  - List with sublists
    - One
    - One
      - Two
        - Three
          - Four
      - Two
  - List completed

Which is the expected output. When I deleted the name of an item through the Workflowy app, I got (Undefined) for that particular item, again as expected.

Could you please double check that the items you are trying to display are in fact not empty? If not, are the items somehow special? For example - shared items, mirrors, references, containing formatted text, etc. If you could share some examples of the actual items that are missing, it would be great. Especially the shared items could be a problem.

The Workflowy client (this package) includes thorough validation of the actual Workflowy API located at workflowy.com, so any data that is received is properly validated, and if there were some lists with parts of data missing (e.g. missing name), there would be errors.

There is a way to check if Workflowy.com returns expected raw data - if the list of items returned were incomplete for some reason, it might manifest as the issue you described. To check for this, please run this command:

const client = workflowy.getClient();

const treeData = await client.getTreeData(); // This is the actual `workflowy.com/get_tree_data` endpoint response

console.log(treeData.items); // The `items` should include all the items in the Workflowy document
console.log(treeData.items.length); // How many items were returned

When you run the command, you can check how many items were returned. If the number is round, that could raise some suspicion that there might be some pagination going on. I have never encountered that though.

Finally, I would like to stress one thing - when using the client, the workflowy.com data is loaded only once, and then the data is stored in memory (until the const workflowy = new WorkFlowy(...); instance seizes to exist). So if you create some items and then try to list the whole document using the same in-memory instance, it is possible that you could see only the new items if you created. If you run the script again though, all of the data is re-loaded from the workflowy.com API. So if you see the items you created after you've re-run the script, then it means that there is something "wrong" with the items that you cannot see, but over all the data retrieval works.

[karelklima]

I have done some more testing with shared nodes and I have come to the conclusion that that is what's causing the issue here - my guess is that those (Untitled) nodes are nodes created by somebody else shared with your Workflowy account. I was able to reproduce such scenario.

In order to support the shared nodes, some non trivial changes need to be made. I'll run some more experiments and will try to see what needs to get improved exactly.

[ogt]

(responding of behald of @sushmashetty305 )
Ok. So the methodology we planned to follow in our project was to create a role account for the API and invite that account with full priviledges to the relevant workflowy nodes ( nodes under them are created by anyone in our engineering team).
It seems that the role account needs to be the creator of all the nodes - which as you pointed out is equivalent to giving to the API the credentials of the user of a single user maintained workflowy tree .

So we are a bit stuck :-) . It seems that the current module implementation is for single-user uses of workflowy.

[karelklima]

@ogt @sushmashetty305 I was able to quickly implement (partial) support for shared lists / documents, which could be sufficient for your use case.

Could you please try it out with the newest version? https://www.npmjs.com/package/workflowy/v/2.5.0

What works: reading of shared lists, even transitively shared (e.g. shared list shared by email directly contains another shared list shared by URL).

Modification / making changes to the content of shared lists should work as well, provided that the user has full privileges.

What probably doesn't work - trying to re-share a shared list, moving the shared list root node around, traversing from the shared list content via parent relationship to the main list. More testing needed in these areas.

[sushmashetty305]

@karelklima Thank you for the upgrade! 👍