|
|
|
# Storing Files
|
|
|
|
|
|
|
|
## Concept
|
|
|
|
|
|
|
|
The concept to having files saved in the database is that any attribute may be defined as a file.
|
|
|
|
|
|
|
|
```xml
|
| ... | ... | @@ -28,6 +30,8 @@ In the universe, an attribute can be identified as being a file by it's baseData |
|
|
|
|
|
|
|
The attribute's permissions are handled as usual - if it's available in a transition, it may be set.
|
|
|
|
|
|
|
|
## Upload
|
|
|
|
|
|
|
|
To set (upload) a file, it needs to be packed into the json request of any transition which includes it.
|
|
|
|
|
|
|
|
The attribute must be set to the original file name and the base64 encoded file data, seperated by a semi-colon:
|
| ... | ... | @@ -63,8 +67,12 @@ As seen in the reply, the attribute will be replaced with meta data needed to st |
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
## Download
|
|
|
|
|
|
|
|
As stated in the universe, the file itself can be downloaded via a seperate url:
|
|
|
|
**
|
|
|
|
/data/helpdesk/ticket/3/download/attachment**
|
|
|
|
|
|
|
|
"3" being the ID of the instance, "attachment" the name of the attribute the file is stored in:
|
|
|
|
|
|
|
|
GET /data/helpdesk/ticket/3/download/attachment
|
|
|
|
|
|
|
|
Permission to do so will be the same as a permission to view the instance. |
|
|
\ No newline at end of file |