taiga-docker
taiga-docker copied to clipboard
Webhook Trigger Conditions are not clear
This belongs to taiga-back scusi...
Describe the bug
When I move user stories on the Kanban board, I'd expect the webhook to be fired, as this is a change in the user story item.
However, I see only webhooks for e.g. the creation of new user stories.
This is somehow essential for automation tasks via the API. I'm currently extending the API N8n node for additional resource types like user stories
and tasks
and think the software would benefit a lot.
To Reproduce
- Create a user story - A webhook is sent
- Move the user story (via drag and drop) from new to some other status - No webhook is sent
Expected behavior I would expect this event also to trigger a webhook.
Additional context
For more context. I have deadlines that change per status. If something is on hold
or waiting for feedback
I'd like to automatically change the deadline with N8n to e.g. Today+5d
, depending on where the user story is placed in the Kanban board.
Is there maybe some place to configure which events cause a webhook?
I'm here for any questions (: Thanks in advance!
The best issues are those which solve themselve. Must have misconfigured the url somehow.
It works =)
"diff": {
"status": {
"from": "y",
"to": "z"
},
I now understand the issue that occurs. When I change the state from a user story within the story details, a webhook is send. However, when I do drag and drop the story card on the Kanban board from one to another, the server will not send a webhook.
So I guess that's an issue :sos:
Is there a chance to add a webhook for the drag-and-drop actions?
Thanks in advance ! :)
just ran into this issue, any chance the drag and drop can activate the webhook pretty please?
Same problem there and I am sure the EMAIL setting is correct.
When I try to sent a test email with the command "./taiga-manage.sh sendtestemail" it gives me the message "If you're reading this, it was successful." but nothig was successful.
With the command "./taiga-manage.sh check --deploy" I get the following:
`+ exec docker-compose -f docker-compose.yml -f docker-compose-inits.yml run --rm taiga-manage check --deploy Creating taiga-docker_taiga-manage_run ... done System check identified some issues:
WARNINGS: ?: (security.W001) You do not have 'django.middleware.security.SecurityMiddleware' in your MIDDLEWARE so the SECURE_HSTS_SECONDS, SECURE_CONTENT_TYPE_NOSNIFF, SECURE_BROWSER_XSS_FILTER, and SECURE_SSL_REDIRECT settings will have no effect. ?: (security.W003) You don't appear to be using Django's built-in cross-site request forgery protection via the middleware ('django.middleware.csrf.CsrfViewMiddleware' is not in your MIDDLEWARE). Enabling the middleware is the safest approach to ensure you don't leave any holes. ?: (security.W009) Your SECRET_KEY has less than 50 characters or less than 5 unique characters. Please generate a long and random SECRET_KEY, otherwise many of Django's security-critical features will be vulnerable to attack. ?: (security.W019) You have 'django.middleware.clickjacking.XFrameOptionsMiddleware' in your MIDDLEWARE, but X_FRAME_OPTIONS is not set to 'DENY'. The default is 'SAMEORIGIN', but unless there is a good reason for your site to serve other parts of itself in a frame, you should change it to 'DENY'.
System check identified 4 issues (0 silenced).`
Any support? It is very annoying...
I have the same issue, using docker image taigaio/taiga-back:latest. I set proper (already tested with another app) email settings inside docker-compose.yml and yet no email got sent.
+1
+1
+1
python manage.py sendtestemail [email protected]
works fine, but notifications dont work at all.
Hi @AmoghSaxena ,
After all your related inquiries, the first thing I did is to discard a real bug while sending emails in Taiga.
In order to achieve this, I have downloaded the latests published images for the stable branch (pruning the older ones), and I tried three different SMTP server configurations to validate it (AWS, Gmail and Mailtrap). I can assure you that Taiga (in the 30-mins setup) is able to send emails with a proper configuration.
For documentation purposes, in order to help others, I left here the final working configurations I used in my trials:
# MAILTRAP
EMAIL_BACKEND: "django.core.mail.backends.smtp.EmailBackend"
DEFAULT_FROM_EMAIL: "[email protected]"
EMAIL_USE_TLS: "True"
EMAIL_USE_SSL: "False"
EMAIL_HOST: "sandbox.smtp.mailtrap.io"
EMAIL_PORT: 587
EMAIL_HOST_USER: "6032xxx"
EMAIL_HOST_PASSWORD: "cb8xxx"
# GMAIL
EMAIL_BACKEND: "django.core.mail.backends.smtp.EmailBackend"
DEFAULT_FROM_EMAIL: "[email protected]"
EMAIL_USE_TLS: "True"
EMAIL_USE_SSL: "False"
EMAIL_HOST: "smtp.gmail.com"
EMAIL_PORT: 587
EMAIL_HOST_USER: "[email protected]"
EMAIL_HOST_PASSWORD: "qgfxxx" (Google App password)
# AWS
EMAIL_BACKEND: "django.core.mail.backends.smtp.EmailBackend"
DEFAULT_FROM_EMAIL: "[email protected]"
EMAIL_USE_TLS: "True"
EMAIL_USE_SSL: "False"
EMAIL_HOST: "xxx.amazonaws.com"
EMAIL_PORT: 587
EMAIL_HOST_USER: "AKxxx"
EMAIL_HOST_PASSWORD: "BFtxxx"
Discarding it's a bug, to trace your particular problem we would require more logs in order to offer you help.
Apart from the email configuration itself in the docker-compose.yml
file (as you have already done), the most important clue is offered by the execution logs given by the 'taiga-back' service
.
Can you provide us both the logs when Taiga starts (to verify every involved service has started properly), and the logs after you attempt to send a mail (for example when inviting a new member to join a project) ?
NOTE: You can start Taiga using docker-compose up
instead of the ./launch-all.sh script to verify the logs in real-time.
Thank you in advance