Feature: Table Column Manager

[benloh]

Here's a first pass at a table column manager.

To Test

Test Node Tables

1. Check out dev-bl/table-col-mgr
2. npm run dev -- add a few nodes if you need to
3. Click "Nodes Table" -- all columns are displayed by default
4. Click on the "Gear" icon in the first column table header -- a pop up window with the column names appears
5. Uncheck the columns you don't want to see -- the table column display should update immediately
6. Re-check the columns if you want them visible
7. Close the window when you're done
8. Close the table by clicking on "Graph"
9. Re-open the Nodes table -- the visible columns remain visible

Test Edge Tables

10. Open the Edge Table
11. Show/Hide Columns
12. Leaving the Show/Hide Columns popup open, click on "Nodes Table" -- the "Show/Hide Columns" for Edges should close, and the Nodes Table retains it's own separate list of shown/hidden columns.
13. Re-open Edge Table -- the "Show/Hide Columns" window re-appears because it was left open.

This way the Node Table and Edge Table have independent Show/Hide operations.

A few other notes:

• To save space, I split the "standard" vs "provenance" columns with a <hr/> -- it felt cleaner than calling out "Provenance Columns" in a separate line.
• The shown/hidden columns are NOT saved across sessions -- we really don't have a facility for saving current app state. So you'd have to re-hide columns the next time you load the graph.
• Column headings that are too long are now limited to two lines. Hover over the heading to see the full column name.
• Node tables now default to being sorted by labels
• Edge tables now default to being sorted by the source node
• The coloring of the tables and borders now matches Evan's design

Addresses #316

[benloh]

@jdanish Given that we're way over budget I'm hoping that this functionality for showing/hiding columns is sufficient.

With the next grant we can add UI to reorder, and define sizes, and retain settings via some kind of saving mechanism.

[jdanish]

Thanks! I didn't expect to get anything! This is great.

One minor new issue which might be with the debug button - if you create a new node, you can't get the new node button to re-activate without reloading the page.

I don't think the attribute / provenance split is accurate currently. Attached it a new graph, and the created by and similar traits aren't marked as provenance in the template though they should be, and cmt wouldn't be (maybe a separate line?). Also, it looks like the created and created by columns appear differently in the table and info panel ... that's likely OK, I just couldn't remember if it was intentional.

[jdanish]

Also, the system won't let me download the template - it says things are being edited (likely the same as above?) ...

[jdanish]

Also, node info panel is not changing color anymore?

[benloh]

@jdanish Thanks for the review.

One minor new issue which might be with the debug button - if you create a new node, you can't get the new node button to re-activate without reloading the page.

Yes this is fixed by #416 which is currently in Sri's "Settings" branch #414.

I don't think the attribute / provenance split is accurate currently. Attached it a new graph, and the created by and similar traits aren't marked as provenance in the template though they should be, and cmt wouldn't be (maybe a separate line?).

We should review the template that you're using to see what's going on. The created, createdBy, updated, and updatedBy should automatically be placed in the provenance section, and any field that has isProvenance: true should be there.

I can add another <hr> before cmt if you think it warrants it.

Also, it looks like the created and created by columns appear differently in the table and info panel ... that's likely OK, I just couldn't remember if it was intentional.

Let's review the template to see what's going on.

Also, the system won't let me download the template - it says things are being edited (likely the same as above?) ...

Yeah that's the node lock bug. You can go to the Import/Export tab and click "Force Unlock All" to re-enable template download (and node creation). Again, this shouldn't be a problem once we get that fix in.

Also, node info panel is not changing color anymore?

This likely has to do with the Misc Editor Fixes #420. We'd want to review your template, but more than likely either the type is somehow not matching an existing type, or the default type is selected. Previously we weren't properly auto-selecting the default type (which in most older templates was #eeeeee (almost white) and instead were showing an undefined type (darker gray).

The green "one" and "two" nodes should be showing the right color. If it's not, again, let's look at your template.

[jdanish]

Here is the file / template. I made this new for this build, so in theory if it does / doesn't include isProvenance that's based on your default, right? Maybe just adding "isProvenance = true" to those that are automatically included will clarify? And for the node types I coped and pasted the existing entry, though that doesn't mean it is right.

Archive 2.zip

I can add another

---

before cmt if you think it warrants it.

I think it'd be good.

Lemme know what I can / should test next.

[benloh]

@jdanish Thanks! That's really helpful.

Looks like we're seeing some conflicts with the Settings branch, which is something we need to resolve eventually:

• The new Settings type color definition adds an alpha value, which we were using in the Node/Edge editors to display workable colors. The new color types result in bad color values. The solution here is to properly design/define all the colors -- the question is whether we want to allow users to define a "solid" color and a "transparent" color for the editor (complicated), or we continue to fake it by adding an alpha value (simpler, but obviously needs to be more robust). (Changing the template to use RGB color instead of RGBA colors fixes this for now).

Revisiting the display of the split. I'm not sure what you were expecting. The panel with your Testing5 template should be:

Show/Hide Columns
[ ] Source
[ ] Type
[ ] Target
[ ] NOtes
[ ] Citation
[ ] Weight
----------
[ ] Info Origin
[ ] Created By
[ ] Create
[ ] Updated By
[ ] Updated
-----------
[ ] Cmt

(assuming we add a line before cmt.)
What were you expecting? Is the problem perhaps that the Node and Edge editor's "History" section shows a "Created" field, which actually displays both "Created" and "CreatedBy" in one line?

[jdanish]

Re color - great.

Re template I think I was assuming a missing line of "isProvenance" would default to false rather than true. Not a big deal though we should have the line in there for the future default template to avoid confusion? And either way shouldn't those fields should up in the node info panel if they are visible in the nodes table? The history seems fine.

Thanks!

[jdanish]

OK, confirming colors work when I use RGB. My Visual Studio Code had started auto-filling colors for me with a color picker, which caused that but now that I know, no problem to avoid.

For the provenance, confirmed that if I make some other field like notes provenance, it all behaves as expected. So, the confusion is because created by and a few others appear in tables but not node info, and seem to not need / ignore the provenance tag.

[benloh]

Re template I think I was assuming a missing line of "isProvenance" would default to false rather than true. Not a big deal though we should have the line in there for the future default template to avoid confusion? And either way shouldn't those fields should up in the node info panel if they are visible in the nodes table? The history seems fine.

@jdanish Yeah I should probably refactor this. There are two sets of issues here:

1. The "Created" label in the History view in the Node Editor is actually not exactly automatically generated from the template settings but is hard coded to return both the created and createdBy fields in a single field. Because it's hard coded I didn't think the isProvenance flag is needed. Perhaps a more proper fix would be to add a isHistory flag for any items that are supposed to go in the History section. But I was trying to keep things simple.

   • One possible fix would be to rename the fields createdOn and createdBy. Unfortunately created is a loki-defined field, so we can't easily do that.
   • Another possible fix would be to rename the label in the "History" section to something like "Created On" and "Updated On" to make it a little clearer that it's not related to the template definitions. But that still wouldn't be obvious, and it just clutters up the UI.
   • Another possible fix would be to remove the "History" section altogether and have all fields follow the isProvenance flag. In that case, there won't be a "History" section and all the provenance fields would be displayed in the Provenance tab. I can't remember the exact discussion but I vaguely recall that History was one of the main asks: Feature: Provenance #213 so it seems wrong to remove it again.
   • I'm inclined not to do anything. It can be a little confusing and perhaps I can clarify that in the code and template editing instructions, but trying to fix this would complicate things quite a bit.

2. We actually want to keep Created and CreatedBy separate in the table, otherwise you can't sort by user.

[jdanish]

Got it. That makes sense. Would it be easy to add a comment to the default template that says "This field is edited by Net.Create, please do not change other than setting 'hidden'." That would avoid the issue in the future along with the template editor being clear in some manner (maybe a similar message there). I'd also suggest making those two hidden by default in the default template since no one seems to want it visible if they can use the "info source" field.

Thanks!

[benloh]

@jdanish I want to make sure we understand all the implications here.

Hiding the created and createdBy in the template will mean

• they are also not visible in the Nodes Table
• you would not be able to sort by createdBy
• the "History" section in the Provenance tab will not show "Created"
• infoOrigin is an editable field, so a user could edit the string, making the createdBy user not visible anywhere.

The same thing is true of updated and updatedBy.

So if you hide created and updated you'd end up with a "History" section with nothing in it. And an infoOrigin field where the user name can be removed, and there is no visible evidence of who may have modified the data. Is that really what you want?

In the new Settings editor, created and createdBy can be hidden from the Settings Panel but still active, so teachers would never see it when editing the template, but still visible in the History section and in tables.

[jdanish]

I am inclined to just leave it as-is then. Long-term we likely will want to let template editors control what goes under history or not, but given where we are at budget-wise, let's leave this be for now.

[benloh]

OK to merge.

NOTES

• Updated with dev-dhi-next and Settings Progress 3 - Template Validation, UI Metadata, Editable Global and Node/EdgeDef #414, so templates should be re-created.

[jdanish]

Playing with templates ... awesome.

Minor thing - create a new node, add a new edge, node panel loses color. Click around and it returns.