Describe the solution you'd like
It would be nice to see the Nickname in the Overview, because it's hard to tell which bot is which.

Hello P-Kito, You can rename the template name for the bots. For example bot_zwei.toml you can rename it to bot_yourname.toml
I know that, but the name of the bot often is not the real nickname :P
But yeah... I agree with your temporary solution.
Yeah, I can try to add more stuff into this card. Maybe I can add a option somewhere on the site which infos you want to have shown on the card. Like online time, uid, song, etc...
The only problem I have is I don't want to cram too much information into the !bot list api call, because the more data it has to get the longer it will take to call when the bot has to look up all kinds of information for each refresh.
Caching probably is a good solution for this.
Take your time with this, it's alpha.
So users can disconnect bots without api key, but they can even generate an api key.. is that normal ? xD
Caching works great with immutable data, but when you hit 'refresh' you'll mostly want to have the fresh data... I'll see what I can do in the future.
Depends on your rights configuration. How does your rights.toml look like?
Got it fixed somehow... toml rights configuration is hell of a pain tbh lol
Any suggestions for improvement?
Go big, go for sql. Or not?..
Uuh, that sounds like it just make it 10 times more complicated.
Some people are already confused with the current syntax; I can't imagine now starting to explain users how to write proper sql.
The first time setup would also get more complicated as you would either need a external sql/db interface, or I'd have to write a good interface.
Maybe you could give me an example how you imagined that?
Uuh, that sounds like it just make it 10 times more complicated. ...
@Splamy What about an internet SQLite database and to configure it with the interface (configured options) / Teamspeak (commands).
I think this will be a bit simpler for users and if they want they can configure it with their own risk on the SQLite database
Sent with GitHawk
I still don't get the advantage of an sql database in the backend over a (clean) permission file which you can edit by hand.
What I get from your statement is that you want an interface and/or the possibility to edit the permission file with commands.
Saving Historys, Playlists, Group and User Permissions, Webinterface/Command Configuration..
This is all sounds like having a SQL Backend it could be nice.
The more enhanced the AudioBot becomes, the more you will be in a need of it anyways, in my opinion.
About the part with "explaining users sql"... How many users are "newbis"? How many are not? I am pretty, pretty sure, that alot of them already bring enough experience.
Have a file create_db.sql that they run on first use. That's it - No big deal. They could either configure permission groups in database directly or with webinterface/commands..
Hm, I kind of disagree.
"could be nice" and "will be in a need of it anyways", doesn't say a lot.
What problems does it solve? What does it improve?
Give me examples or some arguments to work with.
Right now all I see is that I would give up the possibility to easily read, modify or copy all such files from the shell or with the editor of my choice.
I currently like to follow the unix philosophy:
Store data and configuration in flat text files - Text file is a universal interface. Easy to create, backup and move to another system.
And for example all tools i know in my server are like that. Easy to configure via simple text file (sshd, systemd, nginx, etc ...)
The ts3ab currently uses a database (key/value tables, not relational, so no sql) in which we store history entries (as this is the only thing I consider not being useful to be edited/read by hand).
And we store api auth tokens in the db.
Funnily some users asked if there is a way to setup an auth token without starting the bot. If it wasn't in the db but a simple txt file they could simply echo "asdf" >> api.txt or something like that.
But that was a desing decision and I left that for now.
I can still always add an interface tool, which would ease acccess to those files, for users which don't want to edit files by hand. This is independend of the back-end.
For me this is always here: Error:
Error getting bot list
Info:
You need corect permissions for "!bot list" and a working auth token.
Message your bot on TS with !bot list and see if it works.
Then get a auth token... I forgot the command...
Put the auth token into the textbox on top and thats it. Should work.
Most helpful comment
I still don't get the advantage of an sql database in the backend over a (clean) permission file which you can edit by hand.
What I get from your statement is that you want an interface and/or the possibility to edit the permission file with commands.