Container, Button, Link, AccessTokens and Variables, Export

Feature Requests
1

Hello,

I’ve discovered DataGerry earlier this year, and I just wanted to say that you guys are doing an awesome job! It’s very flexible, robust, so far performs very well (I’m still filling in the DB) and hits the sweet spot between CMDBuilder and all the rest. I’m very happy with what this software has to offer!

Now, I have a vision for making it the primary tool for our BAU. In almost every company, IT assets are scattered across various locations: different vendors, different regions, and different clouds, among others. DG (as a CMDB) does an excellent job of centralising all the assets. With DG populated properly, I no longer have to try and remember where that spreadsheet is that had the servername-vendor-bastion-user mapping. All I need is access to DG. :slight_smile: Everything is there. So if I need to access server srvprdsapdb007, I look it up in DG and I see where it is and where to find credentials (granted, I have a field for that).

Almost…..

What’s lacking is a couple of features (or perhaps they are available, I just couldn’t find them).

Block / Container

It would be nice to have a “Block” structure control. Nothing fancy, just a flex container, wrapping a couple of items inside. It would have options:

  • orientation (horizontal/vertical) – defines how items are listed here. Directly maps to flex-direction.
  • overflow (wrap/scroll) – what happens when there are too many items to fit in the visible area
  • justify (start/end/centre/…) – directly maps to flex’s justify-content
  • align (start/end/centre/stretch/…) – directly maps to align-items
  • some clever “naming” for other applicable flex controls
  • size (XS/S/M/L/XL(?)) – size of the items in the container, i.e. adjusting text, elements’ sizes (where applicable)

The purpose of this block is to customise the layout in both directions - horizontal and vertical - not just vertical. And by doing so, I can fill the space with all the details I may need. You (the vendor) are not forcing me to create complex or messy layouts - you are giving me the ability to if I choose so. And I’d very much like to have it. I also think many users would benefit from this structural control, as they would not have to build long vertical lists of checkboxes or radio-buttons (which by themselves would benefit from the “Horizontal/Vertical” option IMO)

Containers should be possible to display in the Object’ List view. E.g. I see all the servers and particular containers, e.g. an array of buttons (arranged horizontally) is squeezed into a single cell in the list for each item. This way I can control each asset much faster, w/o having to open its details. Containers with other types (except buttons and links) of items would be represented as read-only, e.g. RadioButton, CheckBox and Select would only display the selected values, and it’s entirely up to me, the operator, to make sure I carefully choose which containers to display in the List view, not to overflow/overwhelm the view.

Button and Link

The other thing I’m lacking is interactive Basic controls: Button and Link. They are what it says on the box - a simple HTML button that fires up a link

  • color
  • text
  • tooltip
  • active – whether greyed out or not
  • visible – where applicable for that particular item in the first place, or should be hidden completely
  • action
    • address (if address it so the same DG server – reuse the current session for auth)
    • custom – a custom javascript to be executed on click for more advanced stuff, requiring multiple http requests or/and additional logic, like a confirmation pop-up, and/or non-GET requests.

It would be great if I could use variables referring to the asset’s properties (in custom script, button text, address, etc.). E.g.[Console](h ttps://portal.cherryservers.com/teams/1111/projects/2222/servers/${asset.ext_id}).

Link

Very much like a Button, but simpler. Might as well be a simplified superset of a button in implementation

  • text
  • address
  • tooltip
  • active
  • visible

Another thing I’m hoping to implement is automated CMDB updates using scheduled jobs externally. I’d like periodically sync my current state with assets already present in the CMDB, comparing both states first and possibly firing alerts if some states mismatch. That logic I can handle outside of CMDB. What I’d like from DG is to allow me to issue multiple access tokens for users. This way I can revoke a single token w/o having to reset the password everywhere that user is being used, should there be a need to (e.g. accidentally pushed to GitHub).

Variables

While it may seem pointless, it might save a substantial amount of time changing the same substring over and over again across all the objects if we could use variables. E.g. if a vendor is renamed, company name changes, access method changes, domain changes, etc., it would be enough to make the change in a single place - the variables - and it would be updated in the UI automatically. Another use case is establishing frameworks – we have multiple clients where I’m hoping to set up DG as the CMDB. Clients differ, domains differ, vendors differ, etc., but the core structure is very familiar. Using variables, I could craft out a template setup, export it and reuse it for all the clients with greatly minimised effort. Additionally, I could rely on those variables in the Link and Button controls, assembling the eventual URL or use them in the Button-triggerred script.

It would be helpful to have variables of different scopes:

  • user-level – an ability to specify variables (key-value pairs) linked to a particular user
  • asset-level
    • an ability to refer to an asset’s properties, e.g. id, name, colour, cpu type, etc.
    • (possibly) an ability to additionally specify variables (key-value pairs) per-asset
  • type-level – an ability to specify variables (key-value pairs) that would be inherited by all objects of that type
  • global-level – an ability to specify variables (key-value pairs) that would be inherited by all types and objects in the DG instance

Each scope could be accessed separately. e.g. ${dg.user.github_id}, ${dg.global.domain}, etc. Perhaps with an ability to access the eventual value, if scopes override it hierarchically, e.g. ${dg.var.locale} (hierarchy: global→type→user).

Variables would be referred to by the ${var_name} syntax, perhaps using extensions similar to bash’s: ${var_name:-default_value_${suffix}}, ${var_name:0:7} (substringing), ${var_name,,} (lowercasing), ${var_name^^} (upper-casing), ${var_name##*/} (#, ##, %, %%, /, // for replacement locators); where applicable – using the $(javascript code here, manipulating ${variables} or defining the conditionals)

Export/Import

I found that I can export objects, types, etc. separately, i.e. one-by-one. I could not find a way to export all the types (or multi-selected types), categories, or import any of the importables in bulk (I could only import objects and types one file at a time). It would be great if we could export/import more robustly. Dumping the whole DB would also be an option I guess, I just didn’t find instructions on how to do that.

Alright, enough rambling :slight_smile:

I see a lot of potential in DataGerry. It has the potential of becoming the main tool used in technitians’ BAU, having to juggle multiple providers, multiple infras all the time. Having it all in one place with some interactive controls sounds very tempting.

I could try and craft out the skeleton of those features myself, but I really, REALLY suck at UI things: CSS, design, so I would not be able to finish the effort completely. And usually PRs mean the feature must be complete…