docs update

Author: shaswot77

docs/configuringUiJson.md

@@ -147,6 +147,7 @@ The `fieldGroup` field groups a number of other controls together and, optionall
         "type": "fieldGroup",
         "name": "advancedLabelsGroup",
         "label": "Advanced Options",
+        "isInline": true,
         "visible": {
             "advancedLabels": "show"
         },
@@ -159,9 +160,50 @@ The `fieldGroup` field groups a number of other controls together and, optionall
 ```
 More information about the syntax of the `visible` node can be found on the [Plugin Field Types](https://squaredup-eng.atlassian.net/wiki/spaces/PPD/pages/26922639097857/Plugin+Field+Types) page in Confluence.
 
-There is no real visibility of the `fieldGroup` control in the UI. If it's conditionally visible and the condition is false, it's completely absent from the UI. If it's not conditionally visible, or the condition is true, the child controls appear in the UI just as they would if they were not in a `fieldGroup`.
+**Controlling UI Rendering with `displayAs`**
 
-There is no useful presence in the `pluginConfig` object for this field type.
+You can use `displayAs` to control how components render in the UI. There are three `displayAs` options: `"tabs"`, `"tab"`, and `"inline-fields"`.
+
+- `"tabs"` and `"inline-fields"` are **top-level** `displayAs` options, meaning they define how the main component is displayed.  
+- `"tab"` is used **within** a `"tabs"` structure to define individual tabs.  
+
+**Important Note**
+When a `fieldGroup` has `"displayAs": "tabs"`, its `fields` property **must** contain child `fieldGroups` with `"displayAs": "tab"`. Without this structure, the UI will not render properly.
+
+### Example: Working `tabs` Template
+
+```json
+{
+    "type": "fieldGroup",
+    "name": "webApiConfig",
+    "visible": "true",
+    "displayAs": "tabs",
+    "fields": [
+        {
+            "type": "fieldGroup",
+            "name": "basics",
+            "visible": "true",
+            "displayAs": "tab",
+            "label": "Basics",
+            "fields": [...]
+        },
+        {
+            "type": "fieldGroup",
+            "name": "parameters",
+            "displayAs": "tab",
+            "label": "Parameters",
+            "visible": {
+                "httpMethod": "post"
+            },
+            "fields": [...]
+        }
+    ]
+}
+```
+
+This ensures that the UI correctly renders the tabbed structure.
+
+By default, when there is no `displayAs` property, the `fieldGroup` is not rendered in the UI only the `fields` referenced in its `fields` property. If a `fieldGroup` is conditionally visible and the condition is false, it's completely absent from the UI. If a `fieldGroup` is not conditionally visible, or the condition is true, the child controls appear in the UI (if `displayAs` isn't used the fields appear just as they would if they were not in a `fieldGroup`).
 
 ### key-value
 The `key-value` field allows the user to add an arbitrary number of key-value pairs:

docs/newPluginBase.md

@@ -1,4 +1,4 @@
-# Writing a new Plugin
+# Creating a new Plugin Base
 
   - [Getting Started](#getting-started)
   - [`metadata.json`](#metadatajson)

docs/testingAPlugin.md

@@ -67,9 +67,9 @@ Imported 37 vertices and 0 edges:
 
 Testing readDataSource()
 ? Which dataStreamName do you want to test? (Use arrow keys)
-> (Quit) 
-  appHealth 
-  stuffUnscoped 
+> (Quit)
+  appHealth
+  stuffUnscoped
 ```
 
 (In the example above, the import is returning hard-coded objects, which is why it appears to work even though the preceding `testConfig()` test call showed errors).
@@ -107,4 +107,4 @@ Testing appHealth - matches: {"sourceType":{"type":"equals","value":"mySortOfApp
   stuffUnscoped
 ```
 
-Note at this time that the script returns the raw payload from each call on `readDataSource()`; it does not honour the `rowPath` setting you have chosen. You should check the output visually to check that the data you wish to see in dashboards is actually present at the appropriate location in the payload your plugin returns for each stream.
+Note at this time that the script returns the raw payload from each call on `readDataSource()`; it does not honour the `rowPath` setting you have chosen. You should check the output visually to check that the data you wish to see in dashboards is actually present at the appropriate location in the payload your plugin returns for each stream.

docs/writingANewPlugin.md

@@ -119,4 +119,52 @@ Given a version number MAJOR.MINOR.PATCH, increment the:
 
 Breaking changes to a plugin (i.e., incrementing the MAJOR version) will result in a new version of that plugin being made available alongside the existing, older version. In this unlikely scenario, you should create a whole new source directory, `plugins/`_plugin-name_`/v`_N_ for each new major version.
 
-Any changes to the MINOR or PATCH numbers will simply result in the existing plugin being upgraded/updated in-place, so care should be taken to ensure your plugin continues to work with older, existing configuration payloads being passed to your plugin handler.
+Any changes to the MINOR or PATCH numbers will simply result in the existing plugin being upgraded/updated in-place, so care should be taken to ensure your plugin continues to work with older, existing configuration payloads being passed to your plugin handler.
+
+## Minimal Viable Plugin
+**Must**
+
++ Out-of-box dashboard - Dashboards created on setup Guideline for creating OOB scopes and dashboards
+
++ Basic Data Source
+
++ At least one Data Stream
+
++ Test configuration button
+
++ Handle all plugin import errors
+
+**Should**
+
++ Mustache should support the standard promises
+
++ Use Configurable Datastreams where appropriate
+
++ Contain Vertices and Edges for imported objects
+
++ Populating Configurable Datastream with Autocomplete values
+
+## Guidelines for plugin writing
+
+| **Category**   | **Description**  |
+| -------------- | ------------- |
+| Versioning | Use patch version change for small bug fixes <br> Use minor version changes for new data streams, text changes, internal performance improvements, added paging <br> Configuration with lower version of the plugin should work with upgraded plugin to a later version (non major) <br> When a plugin change will cause a breaking change communicate this to PMs and analyse the usage of the plugin and data stream to decide how best to handle it <br> Examples of breaking changes: <br><ul><li> Use major version change for Data Stream change that makes pervious version of same Data Stream to break (but consider creating a new data stream instead, liaise with PM) </li><li> Use major version change if removing certain objects from the graph, or if moving them over into data streams as this would break tiles where they are used as scope </li></ul>
+| Keywords | Include a relevant set of keywords in the metadata.json file. <br> Do not include the plugin name <br> Include relevant datastream references, e.g. BigQuery or Kusto. <br> Include related search terms, e.g. CI/CD, Database |
+| Spelling | American (not British) for all UI visible information (plugin name, description, data stream names) |
+| Data Stream metadata/columns | Every column should have a shape specified <br> Every column should have a name and a display name. The display name should typically be Title Case. |
+| External Links | A link should be added to all imported objects to take the user to the relevant platform, e.g. the Host in the Azure Portal, via the links property on imported nodes. <br> When it makes sense, a link should be included in the datastream data too. The column must be called “Link”. |
+| Timeframe | Whenever possible, all data streams should support timeframes, obeying the start/end dates included in the event. <br> Exception to the rule: data streams where it does not make sense to support a timeframe (e.g. current open alerts). Until such time that we can have a better visual cue, these data streams name should be appended with “Anytime” e.g. Open Incidents (Anytime) <br> Exception to the rule: some Health/Status data streams that show “current” data.
+| Health | Whenever possible, a datastream called “Health” for each imported node type should be included. |
+| Unscoped Data Streams | There must never be any unscoped data streams. |
+| Nodes / Objects | Where it makes sense, a plugin should create a top-level node that represents the account/organisation/instance, e.g. Azure subscription, Github organization. <br> The platform will create a node that represents the plugin itself and edges will be added automatically to top-level nodes such as the Github organization. <br> Add a link for each object to the tool, using the “links“ property (e.g. see the Dynatrace plugin) <br> Consider normalising the casing for case insensitive properties on the imported objects to ensure that correlation can work between them |
+
+## Dictionary
+| **Word (standard display name)** | **Synonyms** |
+|-------------|-----------|
+| CPU | Processor <br> Memory |
+| Disk | Volume
+| Response Time | Response <br> HTTP Response|
+| Availability | Synthetic <br> Check |
+| Hosts | Server |
+| Latest | Top 1 <br> Current <br> Most Recent |
+| Status | State <br> Health |