Doener
February 27, 2024, 8:05am
1
Used Zammad version: 6.2
Used Zammad installation type: (docker-compose)
Operating system: Ubuntu 22.04
Browser + version: Chrome latest
Expected behavior:
following this I want to change the default ticket type to email on creation
Actual behavior:
root **@**container /docker/zammad # docker compose exec -u 0 -it zammad-railsserver bash
root@5a53498e6754:/opt/zammad# rails c
I, [2024-02-27T07:59:08.686428 #11232 ] INFO – : ActionCable is using the redis instance at redis://zammad-redis:6379.
I, [2024-02-27T07:59:08.697429#11232-6000] INFO – : Using memcached as Rails cache store.
I, [2024-02-27T07:59:08.697491#11232-6000] INFO – : Using the Redis back end for Zammad’s web socket session store.
Loading production environment (Rails 7.0.8)
[1] pry(main)> Setting.set(‘ui_ticket_create_default_type’, ‘email-out’)
RuntimeError: Can’t find config setting ‘ui_ticket_create_default_type’
from /opt/zammad/app/models/setting.rb:39:in `set’
Steps to reproduce the behavior:
above command on every execution
Hi @Doener . What happens if you submit a Setting.count
?
Doener
March 26, 2024, 2:42pm
3
sorry for the delayed answer
when I run your command
[3] pry(main)> Setting.count
=> 0
Hi @Doener . This means your database is empty, or you’re using the nulldb
adapter and no database connection is established. Please check your docker-compose.yml
and compare it to the upstream version, and make adjustment - if needed.
Doener
March 27, 2024, 12:16pm
5
Hi @fliebe92 I’m using Zammad since several years and I have a total of four Zammad instances.
To debug this error I just executed the command on all instances, all with the same error. Either I’m using the command incorrectly or there is an underlaying problem here which I can not see.
All instances are using the current zammad-docker-compose/docker-compose.yml at master · zammad/zammad-docker-compose · GitHub docker-compose from the repository and are on the newest 6.2 version.
Doener
March 27, 2024, 2:28pm
7
thank you for the hint, unfortunately nothing changed
docker compose exec -it zammad-railsserver /bin/bash
zammad@14d4ba7f643e:~$ bin/rails c -e production
I, [2024-03-27T14:27:25.987658 #14482] INFO -- : ActionCable is using the redis instance at redis://zammad-redis:6379.
I, [2024-03-27T14:27:25.995461#14482-6000] INFO -- : Using memcached as Rails cache store.
I, [2024-03-27T14:27:25.995525#14482-6000] INFO -- : Using the Redis back end for Zammad's web socket session store.
Loading production environment (Rails 7.0.8.1)
[1] pry(main)> Setting.count
=> 0
What happens when you check the config/database.yml
in the zammad-railsserver
container?
Doener
March 27, 2024, 2:50pm
9
zammad:master
← zammad:fix-container-env
My versions are
```
Docker version 24.0.5, build ced0996
Docker Compose versi… on v2.20.2
```
I dug deeper and noticed that the `.env` suggestion right now is tag version `66` which is fairly old (we're at `119` right now). Suddendly it works. The image version is very important and should be bumped together with this PR to reduce confusions for others just like I had.
With this the entrypoint variant with exec also works as expected:
```
root@dockertest:/opt/zammad-docker-compose# docker exec -ti zammad-docker-compose-zammad-railsserver-1 /docker-entrypoint.sh rails r "pp Setting.count"
I, [2023-08-23T18:53:15.098150 #32] INFO -- : ActionCable is using the redis instance at redis://zammad-redis:6379.
I, [2023-08-23T18:53:15.114664#32-5380] INFO -- : Using memcached as Rails cache store.
I, [2023-08-23T18:53:15.114785#32-5380] INFO -- : Using the Redis back end for Zammad's web socket session store.
I, [2023-08-23T18:53:16.487167#32-5380] INFO -- : Setting.set('models_searchable', ["Chat::Session", "KnowledgeBase::Answer::Translation", "Organization", "Ticket", "User"])
251
```
Sorry for the confusion on my end here.
---
> We'd have to make sure this is clearly documented. What do you think?
Definitely should be documented. It's not straight forward.
We also could implement some kind of wrapper like we have in package installations `zammad run ...`. Just as an idea for lazy people like me. That variant is still shorter than the entrypoint variant. But that's just me possibly.
---
Btw I also build a local container to test my `bash` variant by defining bash to be the shell to be in the container.
That variant however was not solving my above points so I discarded it.
this works though, however like stated in the Issue it is nowhere documented
I executed the command like in the issue and the config got changed and everything works. Thanks for the help
It is documented, see here (hint down below).
Doener
March 27, 2024, 3:08pm
11
then excuse the oversight on my part
1 Like
No worries, we’re here to help