Unexpected behaviour: panel with single category uses emoji & button title from locale

[itsmaty]

Since the pr templates states i have to create an issue....

I created a panel with a single category and was irritated that the button on the panel didn´t refelct my selected emoji and title of the category as expected. So i looked up the implementation here and was surprised to see that the logic implements that when the panel has a single button some fixxed emoji and title from the locales are used (which can´t be chnaged).

I see the idea/reason that if you only have a panel for a single category you may want the button to say something else than the categorys title but first of all this should be changeable and secondly it would be a better implementation to be able to send single categorys from the categorys tab.

I created a PR: #617

[RooRay]

I agree that it should be changeable rather than forcing a specific option but:

Chances are most people with only one category will be using a generic, catch-all name like 'Support' or 'Tickets' which may not communicate clearly what clicking on the button under the panel will do which might confuse some people looking to open a ticket. It's a bit more clear if the button states what the action does (open a ticket) than potentially just say 'Support' or something else which could be mistaken. If a user sees multiple categories, which are more likely to have more descriptive names (e.g. 'Game Support', 'Billing Support', etc) they are more likely to realise that these buttons relate to specific categories/departments than being something else like an info button.

With this in mind, there probably should be an option to change it if someone wants it.

[itsmaty]

As stated, i see the reason why it was done this way and agree with you.
The correct way would be to add another field to the category configuration where you can set the button title but that would involve more changes, like a another database column. Maybe I am going to look into this.

What I think would be a better approach for now, without changing the database scheme, is adding a field to the general settings where you can set the default button title and emoji. What i remember the "locales" where also the emoji and label come from is already saved in the database and could easily mutated.

The general problem is to be honest that the panel has some fundamental design flaws and would need to be recreated from scratch. But still this is the easiest self-host ticket bot out there and its still fantastic that this one even has a panel where you can dynamically adjust configuration.

[itsmaty]

On the other hand... if you add more than one category to a panel you get the category titles. Would this also be confusing? Maybe, but people would figure out they have to change the category name to reflect in the Button. So why chnage this when you only have one category?

[RooRay]

The correct way would be to add another field to the category configuration where you can set the button title but that would involve more changes

I agree this would probably require a new column in the database which might put @eartharoid off implementing it until the next major release

The general problem is to be honest that the panel has some fundamental design flaws and would need to be recreated from scratch

I believe this is planned for the next major release since there are a few other flaws and undesirable design choices needing fixed

adding a field to the general settings where you can set the default button title and emoji

I was thinking more adding a field for the panel creator where if only one category is used to show a checkbox asking if you wanted to use the category label and emoji like this:

(please ignore that the label technically doesn't make sense)

Since I wasn't sure if overwriting the locales in the db would also mean it overwrote them for everyone else using that locale (thus wouldn't really work on the public bot, or any instance being used by >1 server using the same language and 1 category) but I think your idea is probably better in the long-run, and I agree it's a bit of a silly design oversight that should be fixed ASAP

Thanks for your contributions so far! (and apologies if I've sounded a bit hostile I was rushing a bit between a few things, and its exam season for me 😭)

[itsmaty]

No problem. I think discussing something is important.

Adding a checkbox is actually a pretty good idea and the right option here since it doesn't require a schema change of the database and also doesn't change the current behaviour for people that may be used to it. Obviously not perfect but good enough to fix the problem in the already broken dashboard.

If you want, you could take this from here and create a pr, otherwise i probably can find time to implement this until this weekend.

[RooRay]

No problem. I think discussing something is important.

Adding a checkbox is actually a pretty good idea and the right option here since it doesn't require a schema change of the database and also doesn't change the current behaviour for people that may be used to it. Obviously not perfect but good enough to fix the problem in the already broken dashboard.

If you want, you could take this from here and create a pr, otherwise i probably can find time to implement this until this weekend.

If you're happy to work on it, that would be great since I am a bit busy. Feel free to tag me in your PR when you open it (or if you edit your existing one) and I can review & merge to push this out. Thanks again for your help!

[itsmaty]

well i never worked with svelte but it think i will figure it out, its just a checkbox 👍

[RooRay]

i've hardly even touched js let alone svelte so i'd probably blow everything up 😂😂

[itsmaty]

@eartharoid or @RooRay

How to properly set up the panel locally for testing?

I could blindly implement the checkbox and it would probably work.
But testing it would be better.

Or do you say code review is enough for such a simple change?

Edit:
beste practice would probably be to either have a "dev mode" which dosen´t require discord auth, database connection etc or implement dev containers so you cant start up all the moving parts... panel, db, bot at once

[eartharoid]

I run the bot and portal repos locally, but it should be possible to use a remote bot by changing the IP address in vite.config.js.
Also, change the bot's HTTP_EXTERNAL variable (e.g. http://127.0.0.1:5173) so you're redirected to the Vite dev server and not the integrated server.