UI - New Operations tab

[thfries]

please find this PR resolves #1590

• added new tab
• changed way to control right auth user
• extended api to allow devops path
• utils to add table row now returns row
• crud editor returns explicit cancel action
• crud editor now with option without delete or create

Please let me know if this is the right direction.

Pending topics:

• setting log level for all services is currently not possible
• I m thinking if we should allow to hide unused tabs by configuration (e.g. hide connections and operations for sandbox)
• Need to add validation to avoid invalid json to be used on update

Best regards, Thomas

[thjaeckle]

Hi @thfries
Thanks for the fast first draft 👍

I thought that the different available log levels for each logger could be rendered with a bootstrap button group, e.g. also having different colors - DEBUG maybe light gray, INFO green, WARN yellow and ERROR red.
And the currently active log level could be highlighted in order to see at once glance what is currently configured.

That way, the buttons could show the currently configured log level and could also be used to directly change it.
Table + Editor for this use case seem a little bit too complicated, in my opinion.

[thfries]

Hey @thjaeckle,
thanks for your proposal. Usability is indeed far better and the code is even simpler as before. This is how it looks like now:

I'm not sure about the refresh button: It should not scroll away or may be it is not needed at all?

Best regards, Thomas

[thfries]

added another commit to keep the refresh button visible...

[thjaeckle]

@thfries yes, that looks really great. 👍
Will take a look at the code soon.

I think the api supports changing the log level of e.g. all connectivity instances at once and even of specific instances separately.
In my experience, only changing the levels of all instances at once is required.

[thjaeckle]

Hi @thfries
I just reviewed - looks good 👍
Simple and adds a lot benefit for operating Ditto.

Just 2 newly created files have the wrong copyright year, I mentioned that inline.

Apart from that this would be good for me to merge.

[thjaeckle]

@thfries I totally forgot .. There is another thing to do which would this make even more useful:

There should be for each service (e.g. "things", "gateway") a textfield in which you can enter a new arbitrary logger and also select a log level.
The API supports to add new loggers in the fly - that is e.g. very useful if you just need to have DEBUG logs for a single class - then you just add a logger on-the fly with DEBUG - and e.g. deactivate again after you have collected some DEBUG logs.

And they can even be removed again by setting the log level to "OFF" - which we could also think about.

[thfries]

Hi @thjaeckle ,
thanks for your feedback and your thoughts.
Review comments are fixed.
Regarding your other comments:

• I found no API call to set all loggers of one service at once. But in general we can add a "select all" button on top of all columns to do that. If we need several API calls this would still be possible
• There is an API call to set the level for one logger for all services => therefor we would need a checkbox "apply for all services" on each row?
• adding and deleting loggers sounds interesting, too. If this is a relevant use case, we could add it.

The first one sounds very valuable to still add.
...and I still would like to add a feature to hide unused tabs by the environment definition 😉

If you like, I can add some more improvements to this PR.
I will remove draft state of the PR, so you can decide to merge... as you like

Thank you, @thjaeckle

[thfries]

Hi @thjaeckle,
added the toggles for the main menu and found a bug that the auth header was keeping active after switching an environment.

[thjaeckle]

• I found no API call to set all loggers of one service at once. But in general we can add a "select all" button on top of all columns to do that. If we need several API calls this would still be possible

Your proposal already uses this API to switch all loggers of one service at once - so that works as intended 👍

• There is an API call to set the level for one logger for all services => therefor we would need a checkbox "apply for all services" on each row?

I don't think that this would be needed.

• adding and deleting loggers sounds interesting, too. If this is a relevant use case, we could add it.

Yes, this is really valuable, as you can e.g. define for a specific class or package a new logger config without that it needs to be "visible" before in the logging overview.
I would prefer to already have it included in this PR - I could also try to contribute that if I find time ..

Please share your thoughts on that :)

[thjaeckle]

@thfries somehow the "Bearer" token for the main user gets lost now when reloading the page via the browser.
Do you also have that behavior?

I managed to add a input field for adding new loggers - and that integrates quite well into your approach.
Will push shortly so you can have a look.
If it is not ok, we can revert the commit again ..

[thfries]

Hi @thjaeckle ,

nice, thank you!
Yes I also observed issues with the bearer but I was not yet able to reproduce it.
Your addition looks nice. I made one comment and I already thought about to split into smaller local functions to improve readability a bit (I think this is best practice). Let me give it a try.

[thfries]

Done. I like your approach. It keeps the needed parameters just where they are needed. Works also for the other buttons. Strange that it didn't work with the event target...

[thjaeckle]

Lgtm