bartvdbraak / omnidash Goto Github PK

View Code? Open in Web Editor NEW

7.0 1.0 1.0 50.67 MB

Self-hostable dashboard using connectors to a multitude of ticketing systems. (SvelteKit, Shadcn-Svelte & Pocketbase)

Home Page: https://omnidash.io

License: GNU General Public License v3.0

TypeScript 17.97% JavaScript 2.35% CSS 0.76% HTML 1.25% Svelte 77.36% Dockerfile 0.28% Shell 0.04%

omnidash's Introduction

Omnidash is an open source ticket sourcing system, consisting of:

PocketBase for ease of extensibility, user and database management
SvelteKit frontend built using design principles from shadcn-svelte
Multiple login flows (username, email, Oauth2)
API Connectors to preset and custom ticket vendors

Omnidash is most useful to Managed Service Providers that have to keep track of customer tickets which aren't yet consolidated into a single system due to customer requirements.

Warning

This project is still in active development and should not be seen as production-ready. Full documentation, guides and examples will be coming soon.

Setup overview

Frontend

To install the project and its dependencies, follow these steps:

Ensure you have pnpm installed on your system. If not, you can install it by running:
```
npm install -g pnpm
```
Run the following command to install the project dependencies:
```
pnpm install
```

To develop this locally, you can use the following command:

pnpm run dev -- --open

Backend

You can run the backend locally by running:

./backend/pocketbase serve

You can use the --help flag to determine if you need additional setup.

Alternatively, you can run our Docker image:

docker run us-central1-docker.pkg.dev/omnidash-414814/omnidash-pb/main

Environment Variables

After setting up the required services, you need to set the corresponding environment variables in the /.env file. To do this, follow these steps:

Make a copy of the .env.example file:
```
cp .env.example .env
```
Open the .env file in a text editor and populate the values for the services mentioned above.

Build

To build the project, execute the following command:

pnpm build

Security

If you discover a security vulnerability within PocketBase, please send an e-mail to bart at vanderbraak.nl.

All reports will be promptly addressed, and you'll be credited accordingly.

Contributing

PocketBase is free and open source project licensed under the GPLv3. You are free to do whatever you want with it, even offering it as a paid service.

You could help continuing its development by:

omnidash's People

Contributors

Stargazers

Watchers

Forkers

offbase-solutions

omnidash's Issues

Add and refactor README badges

Add an End-to-end Testing framework

I am considering the following candidates:

Some comparison details by krazybug on Reddit:

This really depends on your use case and your organisation.

First you need to understand their architecture:

Playwright use the Chrome DevTools Protocol (CDP) which allows automation directly in the browser and is supported by all the modern ones. This means, it doesn't run in the execution loop of the browser and as such needs an external process (Node, ...) to drive it. It's a bit like Selenium, which by default uses its own protocol+implementation to drive the browser (the webdrivers). Note that from the version 4,Selenium is now able to use the CDP protocol and its features.

Cypress is an Electron App (Native JS app on desktop) which embeds the browser window in it. The library and your code is directly injected in the execution loop of the browser and needs to modify its default behaviour to achieve this. It uses its own implementation for this purpose although a smoother integration with CDP is in progress, but it's not exposed via its API. Node is also used but the main part of the control is delegated to the custom injected library (in the same process, I guess). PW (as Puppeteer) delegates this control to the CDP implementation of the browser which is standardised and maintained by the browser providers.

What are some consequences coming from these differences ?

Cypress is limited to Javascript and transpiled languages as it runs in the browser. Playwright is language independant and gets by default JS/TS, Python, C# and Java support. But you can easily use it with other frameworks/languages like RobotFramework for instance.

Cypress needs some adaptation for each type of browser and currently Safari is not supported. Playwright is supported on all the modern browsers and even gets experimental support for native mobile testing.

CP doesn't support tabs. PW does.

Support of Iframes is possible with CP but has sometimes an erratic behaviour and is harder to use than with PW in our experience.

As it runs directly in the browser, you can setup some shortcuts in your test/fixtures for more efficiency with CP. It means that you can also implement Component/Unit tests with it and it's a promising feature. PW is focused on E2E/System tests and you need another framework to handle the Unit/Component testing part (Jest, Karma/Jasmine ...). You have the choice to use a single framework or 2 different with CP. On the opposite your tests are more close to the real end user's experience with PW as with CP which modifies the browser's behaviour.

Although the integration with some high level (Acceptance/BDD) frameworks is possible, it's not as easy and more limited than with PW. For instance, when we integrate CP with CucumberJS the test runner is provided by CP and the structure of your scenarios and your implemented steps is more constraining. PW not only offers an integration with CucumberJS, RobotFramework, Gauge, but CodeceptJS provides also an official and excellent support for it and CP is not on their roadmap.

On the CI aspect. If you don't master the building agents configuration, you probably need a containerisation solution (Docker) to deploy it. We just need npm install for PW.

Another point is about test parallelisation. PW does provide it out of the box for free. CP doesn't. You'll have to subscribe to their SaaS offer to run your tests in parallel, or find some workarounds which are not perfect.

Remote browsing concern: Playwright is compliant with an internal/self hosted Selenium grid (https://playwright.dev/docs/selenium-grid). Both are supported on SaaS solutions (BrowserStack, ...)

On the UI/API aspect, they are relatively close. Both provide a runner, API mocking and fixtures, advanced locators, .... PW uses a classical pattern to manage asynchronicity (async/await) and CP has chosen a kind of promise answer (dot notation, which is in definitive not totally async) to simplify the code with autocompletion. To structure and reuse your code, CP also has a different approach with custom commands to extend the cy keyword which is somewhat similar to the user centric approach of TestingLibrary or Codecept (the I prefix).

I tried to stay as neutral as possible.

You may also consider Webdriver.io in the equation but we don't have tested it extensively.

pre-commit: npx pretty-quick --staged
commit-msg: npx commitlint --edit $1

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

dockerfile

backend/Dockerfile

alpine 3.19.1

github-actions

.github/workflows/linting.yaml

actions/checkout v4.1.7

pnpm/action-setup v4.0.0

actions/setup-node v4.0.2

wearerequired/lint-action v2.3.0

.github/workflows/unlighthouse.yaml

marocchino/sticky-pull-request-comment v2.9.0

actions/checkout v4.1.7

pnpm/action-setup v4.0.0

actions/setup-node v4.0.2

zentered/vercel-preview-url v1.2.0

UnlyEd/github-action-await-vercel v2.0.0

cloudflare/wrangler-action v3.6.1

actions/github-script v7.0.1

actions/github-script v7.0.1

actions/github-script v7.0.1

marocchino/sticky-pull-request-comment v2.9.0

schneegans/dynamic-badges-action v1.7.0

marocchino/sticky-pull-request-comment v2.9.0

marocchino/sticky-pull-request-comment v2.9.0

npm

package.json

@internationalized/date ^3.5.4

bits-ui ^0.21.11

cmdk-sv ^0.0.17

lucide-svelte ^0.394.0

mode-watcher ^0.3.1

pocketbase ^0.21.3

svelte-headless-table ^0.18.2

svelte-sonner ^0.3.24

tailwind-merge ^2.3.0

tailwind-variants ^0.2.1

@sveltejs/adapter-vercel ^5.4.0

@sveltejs/kit ^2.5.18

@sveltejs/vite-plugin-svelte ^3.1.1

@types/eslint 8.56.10

@typescript-eslint/eslint-plugin ^7.15.0

@typescript-eslint/parser ^7.15.0

autoprefixer ^10.4.19

clsx ^2.1.1

eslint ^8.57.0

eslint-config-prettier ^9.1.0

eslint-plugin-svelte ^2.41.0

formsnap ^1.0.1

lint-staged ^15.2.7

postcss ^8.4.39

postcss-load-config ^5.1.0

prettier ^3.3.2

prettier-plugin-svelte ^3.2.5

prettier-plugin-tailwindcss ^0.5.14

svelte ^4.2.18

svelte-check ^3.8.4

sveltekit-superforms ^2.15.2

tailwindcss ^3.4.4

tslib ^2.6.3

typescript ^5.5.3

unlighthouse ^0.13.1

vite ^5.3.2

zod ^3.23.8

xml2js ^0.5.0