[jira] [Closed] (JAMES-3432) Upload: Attachment
[
https://issues.apache.org/jira/browse/JAMES-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3432.
-
Fix Version/s: 3.6.0
Resolution: Fixed
> Upload: Attachment
> --
>
> Key: JAMES-3432
> URL: https://issues.apache.org/jira/browse/JAMES-3432
> Project: James Server
> Issue Type: Sub-task
>Reporter: Nguyễn Việt Đức
>Priority: Major
> Fix For: 3.6.0
>
>
> *Why*?
> User want to upload file/files for an account.
> How?
> *Request*
> To upload a file, the client submits an authenticated POST request to the
> file upload resource - which MUST contain a variable called accountId.
> Sample: "https://jmap.example.com/upload/\{accountId};
> *Response*
> A successful request MUST return a single JSON object with the following
> properties as the response:
> {code:java}
> *accountId*: Id The id of the account used for the call.
> *blobId*: Id The id representing the binary data uploaded. The data for this
> id is immutable. The id only refers to the binary data, not any metadata.
> *type*: String The media type of the file (as specified in [@!RFC6838],
> Section 4.2) as set in the Content-Type header of the upload HTTP request.
> *size*: UnsignedInt The size of the file in octets.
> {code}
> *Note*
> If identical binary content to an existing blob in the account is uploaded,
> the existing blobId MAY be returned.
> Clients should use the blobId returned in a timely manner. Under rare
> circumstances, the server may have deleted the blob before the client uses
> it; the client should keep a reference to the local file so it can upload it
> again in such a situation.
> When an HTTP error response is returned to the client, the server SHOULD
> return a JSON “problem details” object as the response body, as per
> [@!RFC7807].
> As access controls are often determined by the object holding the reference
> to a blob, unreferenced blobs MUST only be accessible to the uploader, even
> in shared accounts.
> *Definition of done*
> {code:java}
> When bob uploads an attachment
> Then an upload response is sent to him
> And using the blobId specified in the upload response, bob can download that
> attachment
> {code}
> Write integration tests for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3432) Upload: Attachment
[
https://issues.apache.org/jira/browse/JAMES-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223310#comment-17223310
]
Benoit Tellier commented on JAMES-3432:
---
https://github.com/linagora/james-project/pull/3957 did contributed upload size
limitation
https://github.com/linagora/james-project/pull/3979 advertises the limit in the
session
> Upload: Attachment
> --
>
> Key: JAMES-3432
> URL: https://issues.apache.org/jira/browse/JAMES-3432
> Project: James Server
> Issue Type: Sub-task
>Reporter: Nguyễn Việt Đức
>Priority: Major
>
> *Why*?
> User want to upload file/files for an account.
> How?
> *Request*
> To upload a file, the client submits an authenticated POST request to the
> file upload resource - which MUST contain a variable called accountId.
> Sample: "https://jmap.example.com/upload/\{accountId};
> *Response*
> A successful request MUST return a single JSON object with the following
> properties as the response:
> {code:java}
> *accountId*: Id The id of the account used for the call.
> *blobId*: Id The id representing the binary data uploaded. The data for this
> id is immutable. The id only refers to the binary data, not any metadata.
> *type*: String The media type of the file (as specified in [@!RFC6838],
> Section 4.2) as set in the Content-Type header of the upload HTTP request.
> *size*: UnsignedInt The size of the file in octets.
> {code}
> *Note*
> If identical binary content to an existing blob in the account is uploaded,
> the existing blobId MAY be returned.
> Clients should use the blobId returned in a timely manner. Under rare
> circumstances, the server may have deleted the blob before the client uses
> it; the client should keep a reference to the local file so it can upload it
> again in such a situation.
> When an HTTP error response is returned to the client, the server SHOULD
> return a JSON “problem details” object as the response body, as per
> [@!RFC7807].
> As access controls are often determined by the object holding the reference
> to a blob, unreferenced blobs MUST only be accessible to the uploader, even
> in shared accounts.
> *Definition of done*
> {code:java}
> When bob uploads an attachment
> Then an upload response is sent to him
> And using the blobId specified in the upload response, bob can download that
> attachment
> {code}
> Write integration tests for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3438) JMAP Saving draft: specify html body
Benoit Tellier created JAMES-3438:
-
Summary: JMAP Saving draft: specify html body
Key: JAMES-3438
URL: https://issues.apache.org/jira/browse/JAMES-3438
Project: James Server
Issue Type: Sub-task
Components: JMAP
Reporter: Benoit Tellier
Assignee: Antoine Duprat
Fix For: 3.6.0
h2. Why
As a user, I want to be able to add a html body to my draft email
h2. How
Implement the html body part of [`Email/set create`
](https://jmap.io/spec-mail.html#emailset)
{code:java}
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k192": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "j...@example.com"
}],
"subject": "World domination",
"receivedAt": "2018-07-10T01:03:11Z",
"sentAt": "2018-07-10T11:03:11+10:00",
"htmlBody": [
{
"partId": "a49d",
"type": "text/html"
}
],
"bodyValues": {
"a49d": {
"value": "
div{font-size:16px}
I have the most brilliant plan. Let me
tell you all about it. What we do is, we
",
"isTruncated": false
}
}
}
}
}, "0" ]]
{code}
Note:
* we don't implement the body text for now, only the html part
* `bodyStructure` is too complex, we only implement with `htmlBody` for now
Restrictions:
* htmlBody MUST contain exactly one body part and it MUST be of type text/html.
* Within an EmailBodyPart:
* The charset property MUST be omitted if a partId is given (the part’s
content is included in bodyValues, and the server may choose any appropriate
encoding).
* The size property MUST be omitted if a partId is given.
* A Content-Transfer-Encoding header field MUST NOT be given.
* Within an EmailBodyValue object, isEncodingProblem and isTruncated MUST be
either false or omitted.
h2. Definition of Done
Write integration tests about email creation with html body and error handlings
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
