JustArchi
commented
1 month ago The API already returns all the defined properties, and of course saves them back, so it seems there is no ASF block here:
How I see it:
- Check swagger spec to discover all recognized properties. Those should be presented normally because swagger defines type for each property, so you can present them nicely in the UI.
- All extra unknown properties should be rendered as some kind of additional view, like @Rudokhvist suggested above. We can't do much with them because we don't know their type (sometimes you can guess from
trueorfalseto be a boolean, but good luck guessing fromnull). - ASF-ui can simply append extra properties from that additional view to final json sent to ASF, so everything will be saved.
Wishlist:
- Plugins can expose config properties through swagger. It's a matter of agreeing on some general path and making ASF-ui parse the types from there. I did it with STD plugin for example.
Aareksio
Checklist
Enhancement purpose
Add ability to edit custom properties in configuration files, that are parsed by third-party plugins.
Solution
I believe it should be a multi-line text area with non-parsed json of unsupported parameters. Upon saving would be nice to check if it's still valid json, if possible, and show error without saving otherwise.
Why currently available solutions are not sufficient?
Currently editing those parameters only possible by directly editing files on disk. For VPS-hosted ASF it will be more convenient to have ability to edit them via ASF-ui
Can you help us with this enhancement idea?
Somehow, I can test and offer feedback, but can't code
Additional info
Theoretically, we can agree on some "well-known" endpoint where plugins should report schema for supported parameters. But it looks a bit hard to implement, so I believe just a field with json should do.