mbehr1 / fishbone

Visual Studio Code extension for interactive fishbone diagrams

Fishbone README

This Visual Studio Code(tm) extension adds support to create interactive fishbone aka Ishikawa diagrams that can be used to

• analyse failures or
• defect reports / perform root cause analysis or
• support FMEAs.

Note: It works well with dlt-logs extension and supports e.g. querying data directly from the DLT log or applying filter automatically in the DLT log.

Note: To start you can use the command New fishbone or create an empty file with extension .fba and simpy open that via regular "Open...".

Note: Title, effects and categories can be directly changed via the UI. Simply click into the corresponding area.

Note: The document supports regular Undo. That's why e.g. commands like "delete effect", "delete rootcause",... are not asking whether you do really want to delete.

A more detailed documentation is available here: Docs.

Features

• allows to create interactive fishbone diagrams with

  • multiple effects
  • causes/categories to aid clustering root causes
  • root causes that
    • can be checked/unchecked or marked as failing
    • can have a background description
    • can have processing instructions.

• diagrams can be nested via

  • add nested fishbone command from the category ... menu or
  • import fishbone command from the category ... menu. On importing new attributes defined in the imported ones will be added. Take care: attributes with same name will not be modified on import. Please check that they have the same meaning.

• supports copy/cut/paste for root causes and categories.

• supports rest queries from

  • https rest server (e.g. JIRA, github, ...)
  • other extensions (currently dlt-logs).

• The rest query results can be used for badges and automatic apply filter (dlt). Details see Docs/Features/Badges.

• summary table to provide a compact overview

  • grouping by effect and category
  • links to jump directly to the particular fishbone view
  • filter for each element

• template-worklow:

  • fba/fishbone analysis files can be used as templates as well. The feature reset all entries resets all values (check-marks), attribute values and comments. To start a new analysis you can simply use the one from any previous analysis, perform reset all entries and save as... with a new name.
  • import fishbone allows to support complex analysis that can be splitted/maintained by topic or different teams. But for analysis they can be imported into a single analysis file.
  • feature reset & reimport all entries performs same reset than reset all entries but at the same time tries to re-imported / update any imported fishbones. This supports multiple teams maintaining different failure templates. For the re-import the relative path is stored and the imported files are searched with those relative paths.

Planned features

• template-workflow: add "lock" feature/flag on imported fishbones to prevent or be aware of changes that will be overwritten/lost with next "reset & reimport".
• support pcap filters similar to dlt log filters
• support text document filters/events working with smart-logs extension.

Known Issues

• still little testing. Expect and please report bugs via github issues.

Contributors

Thanks a lot to :

• Florian Fuerst for the first PR providing markdown support!

Contributions

Any and all test, code or feedback contributions are welcome. Open an issue or create a pull request to make this extension work better for all.

Donations are welcome! (Contact me for commercial use or different license).

GitHub ♥︎ Sponsors are welcome!

Release Notes

See Changelog

Third-party Content

This project leverages the following third party content.

fishbone-chart (1.0.24)

• License: MIT
• Source: https://github.com/thiagoferrax/fishbone-chart
• Note: this was used as the initial basis. I plan to provide the fixes/improvements done here to my github fork.

js-yaml (4.1.0)

• License: MIT
• see npm package js-yaml

jsonpath (1.1.1)

• License: MIT
• see npm package jsonpath

React, material-ui, react-dom, react-scripts, web-vitals: see corresponding npm packages.

fishbone's Issues

conversion function cannot contain javascript Template literals (Template strings)

Problem is that ${} get's treated as an attribute and thus modified...
Need to exclude ${} replacement within conversionFunctions (or reduce to really only ${attributes..*}.

Updating/saving changes fails with '...has changed in the meantime...'

Sometimes after creation of a new file using 'New fishbone...' the first changes cannot be applied.
Apply the edits internally always fail with 'Error: has changed in the meantime'
at f.apply (bulkTextEdits.ts:235)
at async b._performTextEdits (bulkEditService.ts:99)
at async b.perform (bulkEditService.ts:80)
at async _.apply (bulkEditService.ts:191)

Currently the only workaround is to close the file and reopen it.
(I can only reproduce this under windows, not under OS X.)

Export to static HTML page

Hello, there! Thanks for all the effort put in on this awesome extension.

My question is, what if I wanted to export an FBA file to a static HTML web page?

The use case is to provide the fishbones to users who do not have VS Code for "self-service" support, while still allowing devs to use VS Code to create and extend the fishbones.

What do you think?

The automated release is failing 🚨

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

No vsce personal access token specified (set the VSCE_PAT environment variable).

Unfortunately this error doesn't have any additional information. Feel free to kindly ask the author of the semantic-release-vsce plugin to add more helpful information.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Comments edit field should always be visible.

For the main use case: "enter processing comments" the comments field should always be opened. I.e. the Edit button should not be needed for comments.
For background and instruction it makes perfect sense as is as those should rarely be changed.

Printing

HEllo, this is a very nice Tool.
Is there a way to export the diagram and summary for printing for exemple?

multi-selection and checked root cause not visible in high-contrast theme

The badges and checkbox seems well readable in all but the high-contrast theme:

(root cause 1 is checked)
and

See here in dark theme:

Long root cause title cause overlap with ... button

and the edit button should always be on the right side and not below the root cause text.

Added issue_0004.fba to repo for test.

Lower badge strings that reflect numbers are converted to numbers

E.g. a string '1101' returned from a javascript function should be shown in lower Badge as "1101" but is shown as "99+".
If a javascript function returns a string it should be used as if.

Version: 1.8.1

Support Workspace Trust

Hello 👋 I'm from the VS Code team.

Recently, we have been exploring a security feature we refer to as Workspace Trust. This feature is intended to centralize and unify a security conscious decision required by a variety of VS Code features. With workspace trust, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.

Why you should care

We want to make sure that those users have a delightful experience with workspace trust and that includes extension authors deciding how much of their extension is supported in an untrusted workspace. Custom editors are special in that if they cannot at least render in an untrusted state then they will be replaced by a lightweight message telling the user to enable trust. This means that users of your extension will not be able to see their editors and there may even be cases of data loss.

Workspace Trust experience

You can enable the feature with the following setting security.workspace.trust.enabled. Once enabled, you will see the following dialog when opening folders in VS Code.

This dialog is important for allowing the user to make a decision early and understand the impact of their decision. Once you understand the feature, you may want to customize when to display the dialog using the setting security.workspace.trust.startupPrompt.

You can follow the development of Workspace Trust and provide feedback in issue #106488.

Workspace trust API

First off, all of what I am about to say can be found in issue #120251. That issue will include discussion of the feature and any updates to the feature.

The Workspace Trust extension API is now in stable. This allowed us to release the first cut of our guide for onboarding your extension to Workspace Trust. The API is small, so here is a quick look.

You can declare your extension to provide complete, partial or no support in untrusted workspaces using the untrustedWorkspaces capability in package.json.

The following example declares that the extension is supported completely in untrusted workspaces. In this case, the extension is enabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": true
  }
}

The next example declares that the extension is not supported in untrusted workspaces. In this case, the extension is disabled in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": false
  }
}

The third option is to declared limited support. There are three tools provided to you when you select the limited option.

First, if you have a setting that can be configured in the workspace but requires the workspace to be trusted in order to apply the workspace value, then you can include the setting using restrictedConfigurations array property in untrustedWorkspaces object. Doing so, VS Code will ignore the workspace value of these restricted settings when your extension reads these settings values using the VS Code Workspace Configuration API.

The following example declares the settings that are restricted in untrusted workspaces.

"capabilities": {
  "untrustedWorkspaces": {
    "supported": "limited",
    "restrictedConfigurations": [
      "markdown.styles"
    ]
  }
}

Next, you can also check and listen if the current workspace is trusted or not programmatically using the following API:

export namespace workspace {
  /**
   * When true, the user has explicitly trusted the contents of the workspace.
   */
  export const isTrusted: boolean;
  /**
   * Event that fires when the current workspace has been trusted.
   */
  export const onDidGrantWorkspaceTrust: Event<void>;
}

Lastly, you can hide commands or views declaratively with the isWorkspaceTrusted context key in your when clauses.

A far more detailed guide on how to onboard which will be updated as we receive feedback can be found in issue #120251.

Rollout plan

We are planning on enabling this by default in the near future (most likely next release). To prepare for that day, we want to work with you to allow your editor to work seamlessly alongside the trusted workspace experience

Our Asks

The main features that should work for custom editors in an untrusted folder is rendering, viewing, and saving (if applicable). After reviewing your codebase, I believe that your extension does certain things that can be dangerous if the folder contents are malicious (i.e. executing user files as code) therefore I believe that limited is the best option. This involves listening to the trust state changes and disabling certain features in the untrusted state.

Please let me know if you have any question or would like to meet up via voice chat as I would be happy to assist you in getting your extension ready for workspace trust!

Buttons in edit dialog should have better contrast in dark mode

In dark mode themes the buttons "MARK AS OK", ... "CLOSE" are barely readable.

it's ok in light modes.

Vertical gap between checkboxes with badges too small

Following issue was reported (version 0.9):