Some 'node's miss the 'from' field, and have a 'source' instead.

[kaidatavis]

Please add the details of how to reproduce this error.

[RedayY]

The Issue lies within retrieving nodes from the Database. Once the information is retrieved. It does not come in the exact way it has been stored. This is due to the fact that the schema, accepts only certain fields that are defined. Every field that is not defined by the schema, gets simply dropped.

The missing fields make it so once History Map retrieves NODES and inserts them, NODES get stacked ontop of eachother, rather than appearing just as they were upon saving.

To fix this, Shaz has made it so that the REST API accepts every node with every field in the NODE upon creation.

The next task is to make sure nodes get saved in that new format, and make sure that load is working with the new format.

To do this the following needs to be done:

• Make Save work just as it should do in the new data layout
• Make Load accept contents from the new data layout

[RedayY]

# Evidence of stacked nodes bug:

# Normal Node Example

[kaidatavis]

Reday, it is fine if Shaz has made the change that the backend accepts any field that comes with the node. If not, it might be easier to store a copy of the stringfied 'node' in the 'information' field (was called 'additionalInfo'?) in the backend. In this case no change is needed to the REST API .

[RedayY]

Reday, it is fine if Shaz has made the change that the backend accepts any field that comes with the node. If not, it might be easier to store a copy of the stringfied 'node' in the 'information' field (was called 'additionalInfo'?) in the backend. In this case no change is needed to the REST API .

That is what I reported on above :)

To fix this, Shaz has made it so that the REST API accepts every node with every field in the NODE upon creation.

*submission not creation

And Yea I am aware. The next step now is to make sure nodes get submitted in that format. Which is what I am working on currently to resolve this issue finally.

[RedayY]

So here is a small update towards the state of fixing the issue in load.

Here is an example of a session getting passed through the load function: Important thing is that this is a node example of a node without "nodeadditionalinfo". This screenshot is just an example of what gets through the load function

Since the schema has a new field in nodes called "nodeAdditionalInfo", the application must load the contents from each node via nodeAdditionalinfo and add that to the HistoryMap Node array.

So therefore I must loop through the node array from the session and fish out "nodeAdditionalInfo" from each node and insert it.

I altered the function to do this I also made some changes so Saving can work without Issues

Node2DB function has some slight changes too to adjust for this

Once Saving is enabled, it should not cause any issues. However I need to still test this.

[kaidatavis]

@shahzaibkhan I thought we changed 'nodeAdditionalInfo' to just 'info' last time?

Also, did you update the SenseMapAPI to include these changes? The repository seems to be last updated last year.

[RedayY]

Today I have implemented the new saving logic into SenseMap.

I also was able to test it live with the old API. I got saving working, however I stumbled upon this issue.

This is what gets saved in "nodeAdditionalInfo". When you're adding multiple nodes upon saving. SesenMap Console throws you this error.

Error in event handler for tabs.onUpdated: TypeError: Converting circular structure to JSON at Node2DB (chrome-extension://lajblbdkejaddpihfeeihnicfkmiojem/src/historyMap/historyMapData.js:221:25) at chrome-extension://lajblbdkejaddpihfeeihnicfkmiojem/src/historyMap/browser.js:99:5

This is caused by the "node.nodeAdditionalInfo = JSON.stringify(node)" field, that circules around the entire object, and stores all values in "nodeAdditionalInfo". JSON.stringify cannot stringify this.

I've tried stringifying the values of the object to JSON before I stringify them again upon sending it to the DB, however it still threw the same error.

I am unsure if there is a solution to this. Does anyone know how I would fix this ? @kaimdx @shahzaibkhan ?

---

Here is the new saving function and some changes I made to the model.

Node2DB Recording Enabled

Node2DB Recording Disabled

Model Changes

Code added to Browser.js

[RedayY]

Ohh and btw Saving is working so far :) should break as soon shaz has pushed changes to backend API. however fixing should be easy, as its simple refactoring. 👍

[RedayY]

Pushed changes so DB code matches Model Specified

[kaidatavis]

Hi Reday, after talking to Humzah today, the solution is to save historyMap.model.tree instead of the new node from the historyMap.model.nodes. The tree has the information of how to draw all the nodes and edges in historyMap. As a result, this will replace the entire session in the mongodb instead of just adding a new node as it currently is.

[kaidatavis]

To redraw the history map after loading a session, first set historyMap.model.tree to the value of the retrieved session object, such as historyMap.model.tree = retrievedSessionObj,

And then use d3.select('.sm-history-map-container').datum(historyMap.model.tree).call(historyMapView); (line 44 in the historyMap.js), which should draw the history map (not the historyMap.view.redraw() function).

[kaidatavis]

Once these are done, I still need to change 'browser.js' so it knows how to continue a saved session. Currently browser.js only knows how to start a new session. However, this can only be tested once the session load is working.

[RedayY]

solution is to save historyMap.model.tree instead of the new node from the historyMap.model.nodes

Sounds Interesting, however what about the field "Visability" in node that gets added in (Node2DB). I assume we need to add it somewhere else?

I still need to change 'browser.js' so it knows how to continue a saved session.

Right Now backend can Add Nodes to Sessions by passing the node and the session_ID. I believe if we were to change save to work with the entire tree, there may be the case that the backend Schema needs to adjust for saving the tree as well as Save in general. I could however just save the entire tree in Node.info field for now? (as it accepts anything)

[kaidatavis]

Sounds Interesting, however what about the field "Visability" in node that gets added in (Node2DB). I assume we need to add it somewhere else?

That's a good point. Do we know if the 'hidden' nodes are in the 'tree' as well? This will be fine if this is the case.

Right Now backend can Add Nodes to Sessions by passing the node and the session_ID. I believe if we were to change save to work with the entire tree, there may be the case that the backend Schema needs to adjust for saving the tree as well as Save in general. I could however just save the entire tree in Node.info field for now? (as it accepts anything)

Can you ask Shaz to add a new API function for replacing an entire session by session ID? This shouldn't take too much time.

[shahzaibkhan]

Let me know the details : )

[kaidatavis]

Hi Shaz, can you create a new API function to replace an existing session? It take to parameters, the session id and a json obj, which is an entire session.

[RedayY]

That's a good point. Do we know if the 'hidden' nodes are in the 'tree' as well? This will be fine if this is the case.

We can add the part that adds visibility to nodes to when nodes get generated and added. So therefore when we upload the tree to the Backend DB nodes contain the filed visibility.

Hi Shaz, can you create a new API function to replace an existing session? It take to parameters, the session id and a json obj, which is an entire session.

So we simply just take the entire Session and upload it to the DB ? This includes

• SessionName
• nodes array (well with this I mean the tree ?)

Am I right @kaimdx ?

[shahzaibkhan]

@RedayY Can you let me know which function you want to modify?

Once you create a session, you get an id and definitely you will need to push atleast that.

[kaidatavis]

We can add the part that adds visibility to nodes to when nodes get generated and added. So therefore when we upload the tree to the Backend DB nodes contain the filed visibility.

Not exactly sure what you mean. If the 'tree' does not contain the nodes that are marked as 'invisible', it will be difficult to add such nodes after the 'tree' is created because 1) it will not have the information of how to connect to the exist nodes in the tree, and 2) when the session is retrieved from the database, the historymap tree drawing function won't know how to handle these nodes.

[kaidatavis]

So we simply just take the entire Session and upload it to the DB ? This includes SessionName nodes array (well with this I mean the tree ?)

If you d a console log of the 'tree', you can see that it has two parts: an array of 'links' (edges) and an array of nodes. Both needs to be saved.