Attachment files dispatching is now done through `RawAttachmentView`
view that checks for appropiate permissions.
When using the development server this view just redirects to the real
media path of the file.
When using the production server the special redirection header
`X-Accel-Redirect` is used instead to improve efficiency by instructing
the server to dispatch the file instead of django, but you also need the
following configuration (Nginx):
location /attachment-files {
internal;
alias /path/to/taiga/media/attachment-files;
}
It's recommended to also restrict the direct access from outside to the
`attachment-files` directory by using some configuration like this:
location /media/attachment-files {
deny all;
}
First update taiga-vagrant vm if you're using it, you will have access
to the rabbit management console at port 8001 of the host machine.
* Defining tasks
- Tasks must be defined in a `deferred` module of an app, for example,
`taiga.projects.deferred` module.
- Tasks must be decorated and given the name "<app>.<task-name>", for
example in `taiga.projects.deferred` module:
```
from taiga.celery import app
@app.task(name="projects.add")
def add(x, y):
return x + y
```
- Tasks should be at most just wrappers around service functions to
promote re-usability of those functions from other parts of the code,
say, management commands and the like.
* Calling tasks
Tasks should be called using one of the three functions defined in
`taiga.deferred` module:
- `defer`: Use this function if you need to perform some task
asynchronously and GET THE RESULT back later, for example:
```
result = defer("projects.add", x=1, y=2)
...
result.get() # => 3
```
- `call_async`: Use this function when you want to fire off some
task. No result is get back. For example:
```
call_async("projects.email_user", user)
```
- `apply_async`: Is the same as `call_async` but since it's a function
application and you must pass the args and kwargs together as one
parameter each you are allowed to pass celery-specific
extra-options (but bear in mind this is not recommended!)
```
apply_async("projects.email_user", args=(user,), kwargs={}, routing_key="tasks.email")
```
We are already using pg arrays so the unpickle function in sql/tags.sql
is not needed, at least by the moment. I'm removing it because it was
entering in an infinite loop when creating the test database.
Anler Hp
Andrey Antukh
David Barragán Merino
Yamila
David Barragán Merino
Alejandro Alonso
Jesús Espino