Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Just some feedback of the last few releases #669

Open
sbe-arg opened this issue May 10, 2024 · 6 comments
Open

Just some feedback of the last few releases #669

sbe-arg opened this issue May 10, 2024 · 6 comments
Labels
Feature request➕ New feature or request next release/in dev image🚀 This is coming in the next release or was already released if the issue is Closed.

Comments

@sbe-arg
Copy link

sbe-arg commented May 10, 2024

Nice intentional improvements but the solution is working slower and slower even on fresh installs.
That loading of 30 plugins drives me a bit nuts and the occasional error that partial settings have been saved or loaded.

Its becoming more and more unusable for me in prod to secure my networks if I try to keep up with the breaking changes.

Thanks for the efforts and time but I hope we work on usability and stability more than features.

@jokob-sk
Copy link
Owner

Thanks for the feedback @sbe-arg !
The next big piece I want to spend time on is addressing part of your request,that is I'm thanking to build a plugin loader module allowing users to unload unnecessary modules. This will give shorter startup times a quicker configuration iterations.

Let me know what else would improve the experience and ideally if you can help out 🙏

@sbe-arg
Copy link
Author

sbe-arg commented May 10, 2024

In an ideal world Id like to setup everything from environment variables instead of the GUI so the only things I really need to care is to backup my devices file and re import it if I need to start fresh.

@jokob-sk
Copy link
Owner

I'll think about the environment variables suggestion. Still most apps have a DB or config file which needs to be retained.

Also related the settings issue - Implemented a sanity check to block from incomplete settings to be saved (that's already in the latest prod build). I know it's not ideal but I did spent quite some time to address settings/ caching issues in the latest release. Hope you can bear with me a bit and I improve the stability and speed further.

@sbe-arg
Copy link
Author

sbe-arg commented May 10, 2024

I mean yes but not necessarily. If we can re populate everything in the settings via env vars and restore a devices known list you only loose the history of events.

Means we never habe to login to the web ui if we onlt care about notifications of new devices.

Or to accept new devices so they are known.

In my personal use i only care if new devices join a few vlan wifi networks as alert strategy i dont really care about the history more than a few hours.

@jokob-sk
Copy link
Owner

Means we never habe to login to the web ui if we onlt care about notifications of new devices.

You theoretically don't have to log into the UI even now. The app.conf file can be edited manually and restored with the container. Also, currently, you need to log into the UI to restore the devices.csv file.

So far, after re-reading your comments, the priorities for your specific use cases, are:

  1. Faster load times
  2. Preventing incorrect settings to be saved
  3. Settings initialized via env variables

Number 1) I addressed in the above comment as something I'm thinking about already (for about 2-3 months at this point)

Number 2) from the above should be addressed to some degree in the latest production build. I'm explicitly checking if the core setting UI_LANG is being passed to prevent empty settings to be saved:

sanityCheck_notOK = true

I'm happy to improve on it further, if you have suggestions how to address this issue.

Number 3) I'm more then happy if you or someone helps me to achieve a universal way how to initialize any setting via an ENV variable. This has to be done dynamically as new settings are introduced constantly and maintaining the code otherwise would become unsustainable. This also means when users save the given settings in the UI it may be overridden again - so corresponding UI warnings should ideally be shown.

Regarding 1 & 3 - These are again feature requests, which in essence might introduce new bugs, exactly something you asked me not to do and to focus on the stability of the application.

I do really understand, and want to make the application more stable myself, but as you can see even this thread introduced at least 2 more significant features to the app 🙂and I'm meaning this in a good way, because I really think those are great ideas, but my personal time (and sanity) doesn't allow for more thorough QA testing and development speed without the help of the community.

I know you helped me in the past (I think it was making the image smaller?) - I really appreciate it - so if you decide to help out again, I'm really looking forward to it. 🙏

@jokob-sk jokob-sk added the Feature request➕ New feature or request label May 12, 2024
@jokob-sk
Copy link
Owner

Hi @sbe-arg ,

Regarding 1) Faster load times - I've implemented version v0.5 of this in the netalertx-dev image

image

It would be great if you could test this (backup everything first or use a new container) on your end by switching to the above image and letting me know if the issue was resolved.

Make sure you refresh your browser cache - and click the 🔄 refresh button in the top right corner.

Thanks in advance,
j

@jokob-sk jokob-sk added the next release/in dev image🚀 This is coming in the next release or was already released if the issue is Closed. label May 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature request➕ New feature or request next release/in dev image🚀 This is coming in the next release or was already released if the issue is Closed.
Projects
None yet
Development

No branches or pull requests

2 participants