[jira] [Updated] (JAMES-3158) Deprecation of HybridBlobStore
[ https://issues.apache.org/jira/browse/JAMES-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3158: - Description: After the discussion in [https://github.com/linagora/james-project/pull/3331], we decided that the HybridBlobStore should be deprecated first before being completely removed from James. Will be removed after 3.5 release. CachedBlobStore will be the replacement for HybridBlobStore. was:After the discussion in [https://github.com/linagora/james-project/pull/3331], we decided that the HybridBlobStore should be deprecated first before being completely removed from James. > Deprecation of HybridBlobStore > -- > > Key: JAMES-3158 > URL: https://issues.apache.org/jira/browse/JAMES-3158 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > > After the discussion in > [https://github.com/linagora/james-project/pull/3331], we decided that the > HybridBlobStore should be deprecated first before being completely removed > from James. > Will be removed after 3.5 release. > CachedBlobStore will be the replacement for HybridBlobStore. -- 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-3158) Deprecation of HybridBlobStore
Lan Khuat created JAMES-3158: Summary: Deprecation of HybridBlobStore Key: JAMES-3158 URL: https://issues.apache.org/jira/browse/JAMES-3158 Project: James Server Issue Type: Improvement Reporter: Lan Khuat After the discussion in [https://github.com/linagora/james-project/pull/3331], we decided that the HybridBlobStore should be deprecated first before being completely removed from James. -- 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-3156) Removal of HybridBlobStore
[ https://issues.apache.org/jira/browse/JAMES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094398#comment-17094398 ] Lan Khuat commented on JAMES-3156: -- See: https://issues.apache.org/jira/browse/JAMES-3158 > Removal of HybridBlobStore > -- > > Key: JAMES-3156 > URL: https://issues.apache.org/jira/browse/JAMES-3156 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > > HybridBlobStore will be replaced by CacheBlobStore in the upcoming version, > and thus we need to: > * Remove the HybridBlobStore along with all of its tests & configurations. > * Remove related documentation. > * Add an upgrade instruction. -- 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-3156) Removal of HybridBlobStore
Lan Khuat created JAMES-3156: Summary: Removal of HybridBlobStore Key: JAMES-3156 URL: https://issues.apache.org/jira/browse/JAMES-3156 Project: James Server Issue Type: Improvement Reporter: Lan Khuat HybridBlobStore will be replaced by CacheBlobStore in the upcoming version, and thus we need to: * Remove the HybridBlobStore along with all of its tests & configurations. * Remove related documentation. * Add an upgrade instruction. -- 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-3184) Concurrency for consistency tasks
Lan Khuat created JAMES-3184: Summary: Concurrency for consistency tasks Key: JAMES-3184 URL: https://issues.apache.org/jira/browse/JAMES-3184 Project: James Server Issue Type: Improvement Reporter: Lan Khuat We currently limit concurrency of consistency tasks to 1 in order to avoid unbounded concurrency. When running a consistency task, an admin should be able to precise the concurrency he wishes to use. To do so, each task will expose (optional) concurrency parameters, that an admin can provide via query parameters of the corresponding webadmin endpoints. * RecomputeUserFastViewProjectionItems * RecomputeCurrentQuotas * RecomputeMailboxCounters * SolveMailboxInconsistencies * SolveMessageInconsistencies * FullReindexing * UserReindexing * SingleMailboxReindexing * ErrorRecoveryReindexation -- 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-3173) Document inconsistencies in admin procedures
Lan Khuat created JAMES-3173: Summary: Document inconsistencies in admin procedures Key: JAMES-3173 URL: https://issues.apache.org/jira/browse/JAMES-3173 Project: James Server Issue Type: Improvement Reporter: Lan Khuat Update documentation regarding newly added inconsistencies solving tasks: * Recompute mailboxes counters task * Recompute quotas counters task * Fix message inconsistencies task -- 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] [Updated] (JAMES-3372) JMAP Email/get specific unparsed header
[
https://issues.apache.org/jira/browse/JAMES-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3372:
-
Description:
* Fetching a specified header property by adding {{header:{header-field-name}}}
to the request.
* The resulting EmailView JSON will have a {{header:}} \{header-field-name}
value with an associated type RawHeader.
* {header-field-name} can be any series of one or more printable ASCII
characters (i.e., characters that have values between 33 and 126, inclusive),
except for colon ':'
* Header field names are matched case insensitively.
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
was:
* Fetching a specified header property by adding
{{header:\{header-field-name}}} to the request.
* The resulting EmailView JSON will have a {{header:}}{header-field-name}
value with an associated type RawHeader.
* {header-field-name} field names are matched case insensitively.
\{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon ':'
* Header field names are matched case insensitively.
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
> JMAP Email/get specific unparsed header
> ---
>
> Key: JAMES-3372
> URL: https://issues.apache.org/jira/browse/JAMES-3372
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> * Fetching a specified header property by adding
> {{header:{header-field-name}}} to the request.
> * The resulting EmailView JSON will have a {{header:}} \{header-field-name}
> value with an associated type RawHeader.
> * {header-field-name} can be any series of one or more printable ASCII
> characters (i.e., characters that have values between 33 and 126, inclusive),
> except for colon ':'
> * Header field names are matched case insensitively.
> Example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/get",
> {
> "ids": [ "message_id1"],
> "properties": ["header:Subject"]
> },
> "c1"]]
> }
> Will return
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Email/get",
> {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "state": "01",
> "list": [
> {
> "id": "message_id1",
> "header:Subject": "World domination"
> }
> ]
> },
> "c1"]]
> }
> {code}
>
--
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] [Updated] (JAMES-3372) JMAP Email/get specific unparsed header
[
https://issues.apache.org/jira/browse/JAMES-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3372:
-
Description:
* Fetching a specified header property by adding
{{header:\{header-field-name}}} to the request.
* The resulting EmailView JSON will have a {{header:}}{header-field-name}
value with an associated type RawHeader.
* {header-field-name} field names are matched case insensitively.
\{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon ':'
* Header field names are matched case insensitively.
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
was:
Fetching a specified header property by adding {{header:X-HEADER-NAME}} to the
request. The resulting EmailView JSON will have a {{header:X-HEADER-NAME}}
value with an associated type RawHeader.
Header field names are matched case insensitively.
{code:java}
header:{header-field-name}
{header-field-name} field names are matched case insensitively.
{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon (:)
{code}
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
> JMAP Email/get specific unparsed header
> ---
>
> Key: JAMES-3372
> URL: https://issues.apache.org/jira/browse/JAMES-3372
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> * Fetching a specified header property by adding
> {{header:\{header-field-name}}} to the request.
> * The resulting EmailView JSON will have a {{header:}}{header-field-name}
> value with an associated type RawHeader.
> * {header-field-name} field names are matched case insensitively.
> \{header-field-name} means any series of one or more printable ASCII
> characters (i.e., characters that have values between 33 and 126, inclusive),
> except for colon ':'
> * Header field names are matched case insensitively.
> Example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/get",
> {
> "ids": [ "message_id1"],
> "properties": ["header:Subject"]
> },
> "c1"]]
> }
> Will return
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Email/get",
> {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "state": "01",
> "list": [
> {
> "id": "message_id1",
> "header:Subject": "World domination"
> }
> ]
> },
> "c1"]]
> }
> {code}
>
--
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-3372) JMAP Email/get specific unparsed header
Lan Khuat created JAMES-3372:
Summary: JMAP Email/get specific unparsed header
Key: JAMES-3372
URL: https://issues.apache.org/jira/browse/JAMES-3372
Project: James Server
Issue Type: Improvement
Reporter: Lan Khuat
Fetching a specified header property by adding {{header:X-HEADER-NAME}} to the
request. The resulting EmailView JSON will have a {{header:X-HEADER-NAME}}
value with an associated type RawHeader.
{code:java}
header:{header-field-name}
{header-field-name} field names are matched case insensitively.
{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon (:)
{code}
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
--
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] [Updated] (JAMES-3372) JMAP Email/get specific unparsed header
[
https://issues.apache.org/jira/browse/JAMES-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3372:
-
Description:
Fetching a specified header property by adding {{header:X-HEADER-NAME}} to the
request. The resulting EmailView JSON will have a {{header:X-HEADER-NAME}}
value with an associated type RawHeader.
Header field names are matched case insensitively.
{code:java}
header:{header-field-name}
{header-field-name} field names are matched case insensitively.
{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon (:)
{code}
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
was:
Fetching a specified header property by adding {{header:X-HEADER-NAME}} to the
request. The resulting EmailView JSON will have a {{header:X-HEADER-NAME}}
value with an associated type RawHeader.
{code:java}
header:{header-field-name}
{header-field-name} field names are matched case insensitively.
{header-field-name} means any series of one or more printable ASCII characters
(i.e., characters that have values between 33 and 126, inclusive), except for
colon (:)
{code}
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
> JMAP Email/get specific unparsed header
> ---
>
> Key: JAMES-3372
> URL: https://issues.apache.org/jira/browse/JAMES-3372
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> Fetching a specified header property by adding {{header:X-HEADER-NAME}} to
> the request. The resulting EmailView JSON will have a
> {{header:X-HEADER-NAME}} value with an associated type RawHeader.
> Header field names are matched case insensitively.
> {code:java}
> header:{header-field-name}
> {header-field-name} field names are matched case insensitively.
> {header-field-name} means any series of one or more printable ASCII
> characters (i.e., characters that have values between 33 and 126, inclusive),
> except for colon (:)
> {code}
> Example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/get",
> {
> "ids": [ "message_id1"],
> "properties": ["header:Subject"]
> },
> "c1"]]
> }
> Will return
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Email/get",
> {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "state": "01",
> "list": [
> {
> "id": "message_id1",
> "header:Subject": "World domination"
> }
> ]
> },
> "c1"]]
> }
> {code}
>
--
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] [Updated] (JAMES-3372) JMAP Email/get specific unparsed header
[
https://issues.apache.org/jira/browse/JAMES-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3372:
-
Description:
* Fetching a specified header property by adding header: header-field-name to
the request.
* The resulting EmailView JSON will have a {{header:}} header-field-name value
with an associated type RawHeader.
* Header field name can be any series of one or more printable ASCII
characters (i.e., characters that have values between 33 and 126, inclusive),
except for colon ':'
* Header field names are matched case insensitively.
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
was:
* Fetching a specified header property by adding {{header:{header-field-name}}}
to the request.
* The resulting EmailView JSON will have a {{header:}} \{header-field-name}
value with an associated type RawHeader.
* {header-field-name} can be any series of one or more printable ASCII
characters (i.e., characters that have values between 33 and 126, inclusive),
except for colon ':'
* Header field names are matched case insensitively.
Example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:Subject"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:Subject": "World domination"
}
]
},
"c1"]]
}
{code}
> JMAP Email/get specific unparsed header
> ---
>
> Key: JAMES-3372
> URL: https://issues.apache.org/jira/browse/JAMES-3372
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> * Fetching a specified header property by adding header: header-field-name to
> the request.
> * The resulting EmailView JSON will have a {{header:}} header-field-name
> value with an associated type RawHeader.
> * Header field name can be any series of one or more printable ASCII
> characters (i.e., characters that have values between 33 and 126, inclusive),
> except for colon ':'
> * Header field names are matched case insensitively.
> Example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/get",
> {
> "ids": [ "message_id1"],
> "properties": ["header:Subject"]
> },
> "c1"]]
> }
> Will return
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Email/get",
> {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "state": "01",
> "list": [
> {
> "id": "message_id1",
> "header:Subject": "World domination"
> }
> ]
> },
> "c1"]]
> }
> {code}
>
--
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-3370) JMAP Email/get Unparsed headers
Lan Khuat created JAMES-3370:
Summary: JMAP Email/get Unparsed headers
Key: JAMES-3370
URL: https://issues.apache.org/jira/browse/JAMES-3370
Project: James Server
Issue Type: Improvement
Reporter: Lan Khuat
Header field properties are derived from the message header fields. All header
fields may be fetched in a raw form.
[https://jmap.io/spec-mail.html#emails]
{code:java}
The following low-level Email property is specified for complete access to the
header data of the message:
headers: EmailHeader[] (immutable) This is a list of all header fields
[@!RFC5322], in the same order they appear in the message.
An EmailHeader object has the following properties:
- name: String The header field name as defined in [@!RFC5322], with the
same capitalization that it has in the message.
- value: String The header field value as defined in [@!RFC5322], in Raw
form.
{code}
--
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-3366) JMAP Vacation/set implementation
Lan Khuat created JAMES-3366:
Summary: JMAP Vacation/set implementation
Key: JAMES-3366
URL: https://issues.apache.org/jira/browse/JAMES-3366
Project: James Server
Issue Type: Improvement
Reporter: Lan Khuat
h1. *Objective*
Allow submitting modifications to the VacationResponse object using
{{VacationResponse/set}} method.
h1. Example
{code:java}
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail",
"urn:ietf:params:jmap:vacationresponse" ],
"methodCalls": [[ "VacationResponse/set", {
"accountId": "u123456",
"update": {
"singleton": {
"id":"singleton",
"isEnabled": "true",
"fromDate": "2014-10-30T14:12:00+08:00",
"toDate": "2014-18-30T14:12:00+08:00",
"subject": I am in vacation"",
"textBody": "I'm currently enjoying life. Please distrub me
later",
"htmlBody": "I'm currently enjoying life. Please
distrub me later"
}
}
}, "0" ]]
}
Would return
{
"sessionState": "75128aab4b1b",
"methodResponses": [
["VacationResponse/set", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"newState": "01",
"updated": {
"singleton": {}
}
}, "c1"]]
}
{code}
h1. *Corner cases*
* Omitting the capability urn:ietf:params:jmap:vacationresponse should fail
(the method does not exist)
* Modifications to another vacation than "singleton" should be rejected
* creation and deletion should be rejected as there must always be exactly one
vacation response
* from date needs to be before to date
* Manage serialization errors correctly - invalid vacation response must not
lead to a method level error
--
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] [Updated] (JAMES-3416) ElasticSearch indexing should match full email address
[ https://issues.apache.org/jira/browse/JAMES-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3416: - Description: Previously, we want address fields (From, To, Cc...) to be dynamically matched via Elasticsearch indexing configuration. For example, with an email address like: [u...@domain.tld|mailto:u...@domain.tld] we should be able to fetch it using the query with any of the following term: [user, domain.tld, u...@domain.tld] However this setup does not work properly. In the mean time, the main focus should be fetching email using exact matching on address field. h3. The fix Remove all ElasticSearch indexing configuration with uax_url_email tokenizer related to address fields. h3. DoD * Write integration tests to show that ElasticSearch returns the correct addresses when full address is provided in the query. * Adapt existing integration tests related to address partial matching. was: h3. Description Previously, we want address fields (From, To, Cc...) to be dynamically matched via Elasticsearch indexing configuration. For example, with an email address like: [u...@domain.tld|mailto:u...@domain.tld] we should be able to fetch it using the query with any of the following term: [user, domain.tld, u...@domain.tld] However this setup does not work properly. In the mean time, the main focus should be fetching email using exact matching on address field. h3. The fix Remove all ElasticSearch indexing configuration with uax_url_email tokenizer related to address fields. h3. DoD * Write integration tests to show that ElasticSearch returns the correct addresses when full address is provided in the query. * Adapt existing integration tests related to address partial matching. > ElasticSearch indexing should match full email address > -- > > Key: JAMES-3416 > URL: https://issues.apache.org/jira/browse/JAMES-3416 > Project: James Server > Issue Type: Bug > Components: elasticsearch >Reporter: Lan Khuat >Priority: Major > > Previously, we want address fields (From, To, Cc...) to be dynamically > matched via Elasticsearch indexing configuration. For example, with an email > address like: [u...@domain.tld|mailto:u...@domain.tld] we should be able to > fetch it using the query with any of the following term: [user, domain.tld, > u...@domain.tld] > However this setup does not work properly. In the mean time, the main focus > should be fetching email using exact matching on address field. > h3. The fix > Remove all ElasticSearch indexing configuration with uax_url_email tokenizer > related to address fields. > h3. DoD > * Write integration tests to show that ElasticSearch returns the correct > addresses when full address is provided in the query. > * Adapt existing integration tests related to address partial matching. -- 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-3416) ElasticSearch indexing should match full email address
Lan Khuat created JAMES-3416: Summary: ElasticSearch indexing should match full email address Key: JAMES-3416 URL: https://issues.apache.org/jira/browse/JAMES-3416 Project: James Server Issue Type: Bug Components: elasticsearch Reporter: Lan Khuat h3. Description Previously, we want address fields (From, To, Cc...) to be dynamically matched via Elasticsearch indexing configuration. For example, with an email address like: [u...@domain.tld|mailto:u...@domain.tld] we should be able to fetch it using the query with any of the following term: [user, domain.tld, u...@domain.tld] However this setup does not work properly. In the mean time, the main focus should be fetching email using exact matching on address field. h3. The fix Remove all ElasticSearch indexing configuration with uax_url_email tokenizer related to address fields. h3. DoD * Write integration tests to show that ElasticSearch returns the correct addresses when full address is provided in the query. * Adapt existing integration tests related to address partial matching. -- 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] [Closed] (JAMES-3422) Email/set destroy implementation
[
https://issues.apache.org/jira/browse/JAMES-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat closed JAMES-3422.
Resolution: Duplicate
> Email/set destroy implementation
>
>
> Key: JAMES-3422
> URL: https://issues.apache.org/jira/browse/JAMES-3422
> Project: James Server
> Issue Type: Bug
>Reporter: Lan Khuat
>Priority: Major
>
> This is the implementation of the destroy part of Email/set.
> From JMAP specs [https://jmap.io/spec-mail.html#emailset] :
> {quote}Destroying an Email removes it from all Mailboxes to which it
> belonged. To just delete an Email to trash, simply change the mailboxIds
> property, so it is now in the Mailbox with a role property equal to trash,
> and remove all other Mailbox ids.
> {quote}
> {quote}When emptying the trash, clients SHOULD NOT destroy Emails that are
> also in a Mailbox other than trash. For those Emails, they SHOULD just remove
> the trash Mailbox from the Email.
> {quote}
> When destroying an email, it removes it from all mailboxes to which it
> belongs. Any other operation is an update of {{MailboxIds}} and is of no
> concern in this ticket.
> *Example*
> *Request*
> {code:java}
> {
>"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
>"methodCalls": [
>[
>"Email/set",
>{
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "destroy": ["0001"]
>},
>"c1"]
> ]
> }
> {code}
> *Response*
>
> {code:java}
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Mailbox/set",
> {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "newState": "01",
> "destroyed": ["0001"]
> },
> "c1"]]
> }{code}
> *DoD*
> * Write integration tests showing email is getting removed from all
> Mailboxes it belongs to and deleted from the system when doing an Email/set
> destroy
--
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-3422) Email/set destroy implementation
Lan Khuat created JAMES-3422:
Summary: Email/set destroy implementation
Key: JAMES-3422
URL: https://issues.apache.org/jira/browse/JAMES-3422
Project: James Server
Issue Type: Bug
Reporter: Lan Khuat
This is the implementation of the destroy part of Email/set.
>From JMAP specs [https://jmap.io/spec-mail.html#emailset] :
{quote}Destroying an Email removes it from all Mailboxes to which it belonged.
To just delete an Email to trash, simply change the mailboxIds property, so it
is now in the Mailbox with a role property equal to trash, and remove all other
Mailbox ids.
{quote}
{quote}When emptying the trash, clients SHOULD NOT destroy Emails that are also
in a Mailbox other than trash. For those Emails, they SHOULD just remove the
trash Mailbox from the Email.
{quote}
When destroying an email, it removes it from all mailboxes to which it belongs.
Any other operation is an update of {{Mailboxids}} and is of no concern in this
ticket.
*Example*
*Request*
```
{{{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Email/set",
\{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"destroy": ["0001"]
},
"c1"]
]
}}}
```
{{}}
*Response*
```
{{{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Mailbox/set",
\{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"newState": "01",
"destroyed": ["0001"]
},
"c1"]]
}}}
```
{{}}
*DoD*
* Write integration tests showing email is getting removed from all Mailboxes
it belongs to and deleted from the system when doing an Email/set destroy
--
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] [Updated] (JAMES-3422) Email/set destroy implementation
[
https://issues.apache.org/jira/browse/JAMES-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3422:
-
Description:
This is the implementation of the destroy part of Email/set.
>From JMAP specs [https://jmap.io/spec-mail.html#emailset] :
{quote}Destroying an Email removes it from all Mailboxes to which it belonged.
To just delete an Email to trash, simply change the mailboxIds property, so it
is now in the Mailbox with a role property equal to trash, and remove all other
Mailbox ids.
{quote}
{quote}When emptying the trash, clients SHOULD NOT destroy Emails that are also
in a Mailbox other than trash. For those Emails, they SHOULD just remove the
trash Mailbox from the Email.
{quote}
When destroying an email, it removes it from all mailboxes to which it belongs.
Any other operation is an update of {{MailboxIds}} and is of no concern in this
ticket.
*Example*
*Request*
{code:java}
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Email/set",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"destroy": ["0001"]
},
"c1"]
]
}
{code}
*Response*
{code:java}
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Mailbox/set",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"newState": "01",
"destroyed": ["0001"]
},
"c1"]]
}{code}
*DoD*
* Write integration tests showing email is getting removed from all Mailboxes
it belongs to and deleted from the system when doing an Email/set destroy
was:
This is the implementation of the destroy part of Email/set.
>From JMAP specs [https://jmap.io/spec-mail.html#emailset] :
{quote}Destroying an Email removes it from all Mailboxes to which it belonged.
To just delete an Email to trash, simply change the mailboxIds property, so it
is now in the Mailbox with a role property equal to trash, and remove all other
Mailbox ids.
{quote}
{quote}When emptying the trash, clients SHOULD NOT destroy Emails that are also
in a Mailbox other than trash. For those Emails, they SHOULD just remove the
trash Mailbox from the Email.
{quote}
When destroying an email, it removes it from all mailboxes to which it belongs.
Any other operation is an update of {{Mailboxids}} and is of no concern in this
ticket.
*Example*
*Request*
```
{{{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Email/set",
\{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"destroy": ["0001"]
},
"c1"]
]
}}}
```
{{}}
*Response*
```
{{{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Mailbox/set",
\{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"newState": "01",
"destroyed": ["0001"]
},
"c1"]]
}}}
```
{{}}
*DoD*
* Write integration tests showing email is getting removed from all Mailboxes
it belongs to and deleted from the system when doing an Email/set destroy
> Email/set destroy implementation
>
>
> Key: JAMES-3422
> URL: https://issues.apache.org/jira/browse/JAMES-3422
> Project: James Server
> Issue Type: Bug
>Reporter: Lan Khuat
>Priority: Major
>
> This is the implementation of the destroy part of Email/set.
> From JMAP specs [https://jmap.io/spec-mail.html#emailset] :
> {quote}Destroying an Email removes it from all Mailboxes to which it
> belonged. To just delete an Email to trash, simply change the mailboxIds
> property, so it is now in the Mailbox with a role property equal to trash,
> and remove all other Mailbox ids.
> {quote}
> {quote}When emptying the trash, clients SHOULD NOT destroy Emails that are
> also in a Mailbox other than trash. For those Emails, they SHOULD just remove
> the trash Mailbox from the Email.
> {quote}
> When destroying an email, it removes it from all mailboxes to which it
> belongs. Any other operation is an update of {{MailboxIds}} and is of no
> concern in this ticket.
> *Example*
> *Request*
> {code:java}
> {
>"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
>"methodCalls": [
>[
>"Email/set",
>{
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "destroy": ["0001"]
>},
>"c1"]
> ]
> }
> {code}
> *Response*
>
> {code:java}
> {
> "sessionState": "75128aab4b1b",
> "methodResponses": [[
> "Mailbox/set",
> {
> "accountId":
>
[jira] [Created] (JAMES-3361) Sharee should not be able to modify mailbox rights
Lan Khuat created JAMES-3361: Summary: Sharee should not be able to modify mailbox rights Key: JAMES-3361 URL: https://issues.apache.org/jira/browse/JAMES-3361 Project: James Server Issue Type: Improvement Reporter: Lan Khuat A mailbox can be delegated to other users with a set of predefined rights and only the owner can modify the rights. A sharee should not be able to modify their rights as well as other's rights on said mailbox . For security reason, when an user try to modify the rights on a mailbox that does not belong to them, the server should respond with "not found" instead of "insufficient rights" -- 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-3379) Email/get specific parsed headers
Lan Khuat created JAMES-3379:
Summary: Email/get specific parsed headers
Key: JAMES-3379
URL: https://issues.apache.org/jira/browse/JAMES-3379
Project: James Server
Issue Type: Improvement
Reporter: Lan Khuat
Some header fields may be fetched in a parsed form. The structured form that
may be fetched depends on the header.
[https://jmap.io/spec-mail.html#properties-of-the-email-object] 4.1.2
The following parsings should be supported:
* {{:asRaw}} Type: String, raw encoded value
* {{:asText}} Type: String, decoded value
* {{:asAddresses}} Type: EmailAddress[]
* {{:asGroupedAddresses}} Type: EmailAddressGroup[]
* {{:asMessageIds}}: Type String|Null
* {{:asDate}}: Type Date|Null
* {{:asURLs}}: Type: String[]|null
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/get",
{
"ids": [ "message_id1"],
"properties": ["header:X-HEADER-NAME:asText"]
},
"c1"]]
}
Will return
{
"sessionState": "75128aab4b1b",
"methodResponses": [[
"Email/get",
{
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"state": "01",
"list": [
{
"id": "message_id1",
"header:X-HEADER-NAME:asText": "PARSED2"
}
]
},
"c1"]]
}{code}
--
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-3351) JMAP authentication rework
Lan Khuat created JAMES-3351: Summary: JMAP authentication rework Key: JAMES-3351 URL: https://issues.apache.org/jira/browse/JAMES-3351 Project: James Server Issue Type: Improvement Reporter: Lan Khuat We mandate at least one authentication strategy to return a valid result. However, this means that if one authentication strategy is valid then others can be invalid, or both are valid but come from different identities. To avoid this complication, if one of the authentication method is attenpted with wrong credentials the authentication will fail. We should not allow more than one set of credentials. *DOD:* * Rework authentication strategies. * Write a JMAP-Draft and JMAP-RFC-8621 integration test, exercising several authentication strategies, and demonstrating that if any of them fails, then the request is rejected. -- 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] [Updated] (JAMES-3211) Extends mailbox-api EventBus interface
[ https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3211: - Summary: Extends mailbox-api EventBus interface (was: Generalize EventBus) > Extends mailbox-api EventBus interface > -- > > Key: JAMES-3211 > URL: https://issues.apache.org/jira/browse/JAMES-3211 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > > When searching for users by quota ratio if we set the value of the parameters > to 0, the search feature is supposed to return newly created users who have > not receive any email yet at that point. > However, this is not the case due to the quotas are currently being > initialize only after an user receive the first email. > We need an event-driven system to initialize the quotas after an user has > been created successfully. The EventBus in mailbox-api could be generalized > so we can implement it to solve this problem without having to depend on this > module. > > -- 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] [Updated] (JAMES-3211) Extends mailbox-api EventBus interface
[
https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3211:
-
Description:
When searching for users by quota ratio if we set the value of the parameters
to 0 the search feature is supposed to return newly created users who have not
received any email yet at that point. However, this is not the case because the
quotas are currently being initialized only after a user has received the first
email.
We need to initialize user quotas upon user creation time. The problem is there
is currently no event at user creation and since the quota-search feature is a
plugin of James, it cannot be hardwired into the domain logic of user
management to initialize the quota for a just created user.
For quota-search to be initialized/removed for a given user while keeping this
feature as a plugin, we decided to adopt the Event Driven pattern we already
use in mailbox-api. We can create new events related to user management.
*DOD:*
* Extract the EventBus out of mailbox-api in order to make it a utility
component (eventbus-api), then mailbox-api and data-api will depend on that new
module.
* Define a common Event interface in eventbus-api, then each event-bus usage
will define its own sealed event hierarchy implementing Event.
was:
User email storage usage is limited both in size and count via quotas (IMAP
RFC-2087). In order to ease administrating large user bases, the quota search
extension allows administrator to retrieve all users whose email usages are
exceeding a given occupation ratio.
When searching for users by quota ratio if we set the value of the parameters
to 0, for example: {{/quotas/users?minOccupationRatio=0=0}},
the search feature is supposed to return newly created users who have not
received any email yet at that point. However, this is not the case because the
quotas are currently being initialized only after a user has received the first
email.
We need to initialize user quotas upon user creation time. The problem is there
is currently no event at user creation and since the quota-search feature is a
plugin of James, it cannot be hardwired into the domain logic of user
management to initialize the quota for a just created user.
For quota-search to be initialized/removed for a given user while keeping this
feature as a plugin, we decided to adopt the Event Driven pattern we already
use in mailbox-api. We can create new events related to user management.
*DOD:*
* Extract the EventBus out of mailbox-api in order to make it a utility
component (eventbus-api), then mailbox-api and data-api will depend on that new
module.
* Define a common Event interface in eventbus-api, then each event-bus usage
will define its own sealed event hierarchy implementing Event.
> Extends mailbox-api EventBus interface
> --
>
> Key: JAMES-3211
> URL: https://issues.apache.org/jira/browse/JAMES-3211
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When searching for users by quota ratio if we set the value of the parameters
> to 0 the search feature is supposed to return newly created users who have
> not received any email yet at that point. However, this is not the case
> because the quotas are currently being initialized only after a user has
> received the first email.
> We need to initialize user quotas upon user creation time. The problem is
> there is currently no event at user creation and since the quota-search
> feature is a plugin of James, it cannot be hardwired into the domain logic of
> user management to initialize the quota for a just created user.
> For quota-search to be initialized/removed for a given user while keeping
> this feature as a plugin, we decided to adopt the Event Driven pattern we
> already use in mailbox-api. We can create new events related to user
> management.
> *DOD:*
> * Extract the EventBus out of mailbox-api in order to make it a utility
> component (eventbus-api), then mailbox-api and data-api will depend on that
> new module.
> * Define a common Event interface in eventbus-api, then each event-bus usage
> will define its own sealed event hierarchy implementing Event.
--
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] [Updated] (JAMES-3211) Extends mailbox-api EventBus interface
[
https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3211:
-
Description:
User email storage usage is limited both in size and count via quotas (IMAP
RFC-2087). In order to ease administrating large user bases, the quota search
extension allows administrator to retrieve all users whose email usages are
exceeding a given occupation ratio.
When searching for users by quota ratio if we set the value of the parameters
to 0, for example: {{/quotas/users?minOccupationRatio=0=0}},
the search feature is supposed to return newly created users who have not
received any email yet at that point. However, this is not the case because the
quotas are currently being initialized only after a user has received the first
email.
We need to initialize user quotas upon user creation time. The problem is there
is currently no event at user creation and since the quota-search feature is a
plugin of James, it cannot be hardwired into the domain logic of user
management to initialize the quota for a just created user.
For quota-search to be initialized/removed for a given user while keeping this
feature as a plugin, we decided to adopt the Event Driven pattern we already
use in mailbox-api. We can create new events related to user management.
*DOD:*
* Extract the EventBus out of mailbox-api in order to make it a utility
component (eventbus-api), then mailbox-api and data-api will depend on that new
module.
* Define a common Event interface in eventbus-api, then each event-bus usage
will define its own sealed event hierarchy implementing Event.
was:
When searching for users by quota ratio if we set the value of the parameters
to 0, the search feature is supposed to return newly created users who have not
receive any email yet at that point.
However, this is not the case due to the quotas are currently being initialize
only after an user receive the first email.
We need an event-driven system to initialize the quotas after an user has been
created successfully. The EventBus in mailbox-api could be generalized so we
can implement it to solve this problem without having to depend on this module.
> Extends mailbox-api EventBus interface
> --
>
> Key: JAMES-3211
> URL: https://issues.apache.org/jira/browse/JAMES-3211
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User email storage usage is limited both in size and count via quotas (IMAP
> RFC-2087). In order to ease administrating large user bases, the quota search
> extension allows administrator to retrieve all users whose email usages are
> exceeding a given occupation ratio.
> When searching for users by quota ratio if we set the value of the parameters
> to 0, for example:
> {{/quotas/users?minOccupationRatio=0=0}}, the search
> feature is supposed to return newly created users who have not received any
> email yet at that point. However, this is not the case because the quotas are
> currently being initialized only after a user has received the first email.
> We need to initialize user quotas upon user creation time. The problem is
> there is currently no event at user creation and since the quota-search
> feature is a plugin of James, it cannot be hardwired into the domain logic of
> user management to initialize the quota for a just created user.
> For quota-search to be initialized/removed for a given user while keeping
> this feature as a plugin, we decided to adopt the Event Driven pattern we
> already use in mailbox-api. We can create new events related to user
> management.
> *DOD:*
> * Extract the EventBus out of mailbox-api in order to make it a utility
> component (eventbus-api), then mailbox-api and data-api will depend on that
> new module.
> * Define a common Event interface in eventbus-api, then each event-bus usage
> will define its own sealed event hierarchy implementing Event.
--
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-3269) MessageFastView should be using moving averages
Lan Khuat created JAMES-3269: Summary: MessageFastView should be using moving averages Key: JAMES-3269 URL: https://issues.apache.org/jira/browse/JAMES-3269 Project: James Server Issue Type: Improvement Reporter: Lan Khuat MessageFastViewProjection health check currently relies on total count since last reboot and thus, does not correctly reflect latest server state, especially for a long running server instance. *DOD:* Replace the current metric with a counter keeping track of events that happen within a 5 minutes time window. -- 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-3211) Generalize EventBus
Lan Khuat created JAMES-3211: Summary: Generalize EventBus Key: JAMES-3211 URL: https://issues.apache.org/jira/browse/JAMES-3211 Project: James Server Issue Type: Improvement Reporter: Lan Khuat When searching for users by quota ratio if we set the value of the parameters to 0, the search feature is supposed to return newly created users who have not receive any email yet at that point. However, this is not the case due to the quotas are currently being initialize only after an user receive the first email. We need an event-driven system to initialize the quotas after an user has been created successfully. The EventBus in mailbox-api could be generalized so we can implement it to solve this problem without having to depend on this module. -- 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] [Updated] (JAMES-3211) Generalize EventBus
[ https://issues.apache.org/jira/browse/JAMES-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3211: - Description: When searching for users by quota ratio if we set the value of the parameters to 0, the search feature is supposed to return newly created users who have not receive any email yet at that point. However, this is not the case due to the quotas are currently being initialize only after an user receive the first email. We need an event-driven system to initialize the quotas after an user has been created successfully. The EventBus in mailbox-api could be generalized so we can implement it to solve this problem without having to depend on this module. was: When searching for users by quota ratio if we set the value of the parameters to 0, the search feature is supposed to return newly created users who have not receive any email yet at that point. However, this is not the case due to the quotas are currently being initialize only after an user receive the first email. We need an event-driven system to initialize the quotas after an user has been created successfully. The EventBus in mailbox-api could be generalized so we can implement it to solve this problem without having to depend on this module. > Generalize EventBus > --- > > Key: JAMES-3211 > URL: https://issues.apache.org/jira/browse/JAMES-3211 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > > When searching for users by quota ratio if we set the value of the parameters > to 0, the search feature is supposed to return newly created users who have > not receive any email yet at that point. > However, this is not the case due to the quotas are currently being > initialize only after an user receive the first email. > We need an event-driven system to initialize the quotas after an user has > been created successfully. The EventBus in mailbox-api could be generalized > so we can implement it to solve this problem without having to depend on this > module. > > -- 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-3201) Add additional detail about failed mailboxes in reindexing tasks
Lan Khuat created JAMES-3201: Summary: Add additional detail about failed mailboxes in reindexing tasks Key: JAMES-3201 URL: https://issues.apache.org/jira/browse/JAMES-3201 Project: James Server Issue Type: Improvement Reporter: Lan Khuat So far only reindexing on message failures are being reported in the additional details of the tasks. But sometimes, we can have errors on the mailbox level and we currently miss this information. We need to: - Add a mailbox failures field listing ids of mailboxes we failed to reindex. - Update the reindexing process for the failed mailboxes to be indexed again when we run the ErrorRecoveryTask. - Unit test + integration test. -- 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] [Updated] (JAMES-3358) Mailbox/set delete: onDestroyRemoveEmails argument implementation
[
https://issues.apache.org/jira/browse/JAMES-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3358:
-
Description:
Property: {{*onDestroyRemoveEmails*: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to *{{false}}*
* If *{{false}}*, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a \{{mailboxHasEmail}}SetError.
* If *{{true}}*, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{code:java}
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID",
"ifInState": "123",
"create": null,
"destroy": [ "0001" ],
"onDestroyRemoveEmails": true
}
]
]
}
{code}
*Response*
{code:java}
{
"methodResponses": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID", // the requested accountId
"oldState": "123",
"newState": "124",
"created": null,
"destroyed": [ "0001" ]
}
]
],
"sessionState": "abc"
}
{code}
*DOD:*
Integration tests + proof of email deletion when the property is *{{true}}*
Proof of reject of the request if the property is *{{false}}* (with emails
still present in the mailbox)
was:
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a \{{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{code:java}
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID",
"ifInState": "123",
"create": null,
"destroy": [ "0001" ],
"onDestroyRemoveEmails": true
}
]
]
}
{code}
*Response*
{code:java}
{
"methodResponses": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID", // the requested accountId
"oldState": "123",
"newState": "124",
"created": null,
"destroyed": [ "0001" ]
}
]
],
"sessionState": "abc"
}
{code}
*DOD:*
Integration tests + proof of email deletion when the property is
{{true}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
> Mailbox/set delete: onDestroyRemoveEmails argument implementation
> -
>
> Key: JAMES-3358
> URL: https://issues.apache.org/jira/browse/JAMES-3358
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> Property: {{*onDestroyRemoveEmails*: Boolean}}
> Determine whether the emails in a mailbox should be removed/destroyed when
> that mailbox got destroyed.
> * SHOULD default to *{{false}}*
> * If *{{false}}*, any attempt to destroy a Mailbox that still has Emails in
> it will be rejected with a \{{mailboxHasEmail}}SetError.
> * If *{{true}}*, any Emails that were in the Mailbox will be removed from
> it, and if in no other Mailboxes, they will be destroyed when the Mailbox is
> destroyed.
> *Request*
> {code:java}
> {
>"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
>"methodCalls": [
>[
>"Mailbox/set",
>{
> "accountId": "JMAP-ID",
> "ifInState": "123",
> "create": null,
> "destroy": [ "0001" ],
> "onDestroyRemoveEmails": true
>}
>]
>]
> }
> {code}
> *Response*
>
> {code:java}
> {
>"methodResponses": [
>[
>"Mailbox/set",
>{
> "accountId": "JMAP-ID", // the requested accountId
> "oldState": "123",
> "newState": "124",
> "created": null,
> "destroyed": [ "0001" ]
>}
>]
>],
>"sessionState": "abc"
> }
> {code}
> *DOD:*
> Integration tests + proof of email deletion when the property is *{{true}}*
> Proof of reject of the request if the property is *{{false}}* (with emails
[jira] [Updated] (JAMES-3358) Mailbox/set delete: onDestroyRemoveEmails argument implementation
[
https://issues.apache.org/jira/browse/JAMES-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3358:
-
Description:
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a \{{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{code:java}
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID",
"ifInState": "123",
"create": null,
"destroy": [ "0001" ],
"onDestroyRemoveEmails": true
}
]
]
}
{code}
*Response*
{code:java}
{
"methodResponses": [
[
"Mailbox/set",
{
"accountId": "JMAP-ID", // the requested accountId
"oldState": "123",
"newState": "124",
"created": null,
"destroyed": [ "0001" ]
}
]
],
"sessionState": "abc"
}
{code}
*DOD:*
Integration tests + proof of email deletion when the property is
{{true}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
was:
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a \{{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{{```}}
{{
{ "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", "ifInState":
"123", "create": null, "destroy": [ "0001" ], "onDestroyRemoveEmails": true }
]
]
}}}
```
*Response*
```
{{
{ "methodResponses": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", // the
requested accountId "oldState": "123", "newState": "124", "created": null,
"destroyed": [ "0001" ] }
]
],
"sessionState": "abc"
}}}
```
*DOD:*
Integration tests + proof of email deletion when the property is
{{true}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
> Mailbox/set delete: onDestroyRemoveEmails argument implementation
> -
>
> Key: JAMES-3358
> URL: https://issues.apache.org/jira/browse/JAMES-3358
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> Property: {{onDestroyRemoveEmails: Boolean}}
> Determine whether the emails in a mailbox should be removed/destroyed when
> that mailbox got destroyed.
> * SHOULD default to {{false}}
> * If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
> will be rejected with a \{{mailboxHasEmail}}SetError.
> * If {{true}}, any Emails that were in the Mailbox will be removed from it,
> and if in no other Mailboxes, they will be destroyed when the Mailbox is
> destroyed.
> *Request*
> {code:java}
> {
>"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
>"methodCalls": [
>[
>"Mailbox/set",
>{
> "accountId": "JMAP-ID",
> "ifInState": "123",
> "create": null,
> "destroy": [ "0001" ],
> "onDestroyRemoveEmails": true
>}
>]
>]
> }
> {code}
> *Response*
>
> {code:java}
> {
>"methodResponses": [
>[
>"Mailbox/set",
>{
> "accountId": "JMAP-ID", // the requested accountId
> "oldState": "123",
> "newState": "124",
> "created": null,
> "destroyed": [ "0001" ]
>}
>]
>],
>"sessionState": "abc"
> }
> {code}
> *DOD:*
> Integration tests + proof of email deletion when the property is
> {{true}}
> Proof of reject of the request if the property is
> {{false}}
> (with emails still present in the mailbox)
--
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:
[jira] [Updated] (JAMES-3358) Mailbox/set delete: onDestroyRemoveEmails argument implementation
[
https://issues.apache.org/jira/browse/JAMES-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3358:
-
Description:
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a \{{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{{```}}
{{
{ "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", "ifInState":
"123", "create": null, "destroy": [ "0001" ], "onDestroyRemoveEmails": true }
]
]
}}}
```
*Response*
```
{{
{ "methodResponses": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", // the
requested accountId "oldState": "123", "newState": "124", "created": null,
"destroyed": [ "0001" ] }
]
],
"sessionState": "abc"
}}}
```
*DOD:*
Integration tests + proof of email deletion when the property is
{{true}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
was:
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a {{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{{```}}
{{{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Mailbox/set",
\{
"accountId": "JMAP-ID",
"ifInState": "123",
"create": null,
"destroy": [ "0001" ],
"onDestroyRemoveEmails": true
}
]
]
}}}
```
*Response*
```
{{{
"methodResponses": [
[
"Mailbox/set",
\{
"accountId": "JMAP-ID", // the requested accountId
"oldState": "123",
"newState": "124",
"created": null,
"destroyed": [ "0001" ]
}
]
],
"sessionState": "abc"
}}}
```
*DOD:*
Integration tests + proof of email deletion when the property is
{{}}
{{true}}
{{}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
> Mailbox/set delete: onDestroyRemoveEmails argument implementation
> -
>
> Key: JAMES-3358
> URL: https://issues.apache.org/jira/browse/JAMES-3358
> Project: James Server
> Issue Type: Improvement
>Reporter: Lan Khuat
>Priority: Major
>
> Property: {{onDestroyRemoveEmails: Boolean}}
> Determine whether the emails in a mailbox should be removed/destroyed when
> that mailbox got destroyed.
> * SHOULD default to {{false}}
> * If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
> will be rejected with a \{{mailboxHasEmail}}SetError.
> * If {{true}}, any Emails that were in the Mailbox will be removed from it,
> and if in no other Mailboxes, they will be destroyed when the Mailbox is
> destroyed.
> *Request*
> {{```}}
> {{
> { "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
> "methodCalls": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", "ifInState":
> "123", "create": null, "destroy": [ "0001" ], "onDestroyRemoveEmails": true }
> ]
> ]
> }}}
> ```
> *Response*
> ```
> {{
> { "methodResponses": [ [ "Mailbox/set", \\{ "accountId": "JMAP-ID", // the
> requested accountId "oldState": "123", "newState": "124", "created": null,
> "destroyed": [ "0001" ] }
> ]
> ],
> "sessionState": "abc"
> }}}
> ```
>
> *DOD:*
> Integration tests + proof of email deletion when the property is
> {{true}}
> Proof of reject of the request if the property is
> {{false}}
> (with emails still present in the mailbox)
--
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-3358) Mailbox/set delete: onDestroyRemoveEmails argument implementation
Lan Khuat created JAMES-3358:
Summary: Mailbox/set delete: onDestroyRemoveEmails argument
implementation
Key: JAMES-3358
URL: https://issues.apache.org/jira/browse/JAMES-3358
Project: James Server
Issue Type: Improvement
Reporter: Lan Khuat
Property: {{onDestroyRemoveEmails: Boolean}}
Determine whether the emails in a mailbox should be removed/destroyed when that
mailbox got destroyed.
* SHOULD default to {{false}}
* If {{false}}, any attempt to destroy a Mailbox that still has Emails in it
will be rejected with a {{mailboxHasEmail}}SetError.
* If {{true}}, any Emails that were in the Mailbox will be removed from it,
and if in no other Mailboxes, they will be destroyed when the Mailbox is
destroyed.
*Request*
{{```}}
{{{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[
"Mailbox/set",
\{
"accountId": "JMAP-ID",
"ifInState": "123",
"create": null,
"destroy": [ "0001" ],
"onDestroyRemoveEmails": true
}
]
]
}}}
```
*Response*
```
{{{
"methodResponses": [
[
"Mailbox/set",
\{
"accountId": "JMAP-ID", // the requested accountId
"oldState": "123",
"newState": "124",
"created": null,
"destroyed": [ "0001" ]
}
]
],
"sessionState": "abc"
}}}
```
*DOD:*
Integration tests + proof of email deletion when the property is
{{}}
{{true}}
{{}}
Proof of reject of the request if the property is
{{false}}
(with emails still present in the mailbox)
--
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] [Updated] (JAMES-3459) Implement a MailboxChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3459: - Description: >From the spec: [https://jmap.io/spec-core.html#changes] ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name MailboxChangeRepository. First we will implement a memory version of it. h1. How * Define MailboxChange model. * Define a contract for the MailboxChangeRepository. * Implement MemoryMailboxChangeRepository APIs (save, getSinceState) base on the contract. h1. DoD Write unit tests to show that MemoryMailboxChangesRepository is functioning properly. was: >From the spec: https://jmap.io/spec-core.html#changes ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name MailboxChangeStore. First we will implement a memory version of it. h1. How * Define MailboxChange model. * Define a contract for the MailboxChangeStore. * Implement MemoryMailboxChangeStore APIs (save, getFromState,...) base on the contract. h1. DoD Write unit tests to show that MemoryMailboxChangesStore is functioning properly. Summary: Implement a MailboxChangeRepository (was: Implement a MailboxChangeStore) > Implement a MailboxChangeRepository > --- > > Key: JAMES-3459 > URL: https://issues.apache.org/jira/browse/JAMES-3459 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > From the spec: [https://jmap.io/spec-core.html#changes] > ``` > When the state of the set of Foo records in an account changes on the server > (whether due to creation, updates, or deletion), the state property of the > Foo/get response will change. > ``` > We need to store all the changes made to mailbox objects in a table name > MailboxChangeRepository. First we will implement a memory version of it. > h1. How > * Define MailboxChange model. > * Define a contract for the MailboxChangeRepository. > * Implement MemoryMailboxChangeRepository APIs (save, getSinceState) base on > the contract. > h1. DoD > Write unit tests to show that MemoryMailboxChangesRepository is functioning > properly. -- 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-3459) Implement a MailboxChangeStore
Lan Khuat created JAMES-3459: Summary: Implement a MailboxChangeStore Key: JAMES-3459 URL: https://issues.apache.org/jira/browse/JAMES-3459 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat >From the spec: https://jmap.io/spec-core.html#changes ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name MailboxChangeStore. First we will implement a memory version of it. h1. How * Define MailboxChange model. * Define a contract for the MailboxChangeStore. * Implement MemoryMailboxChangeStore APIs (save, getFromState,...) base on the contract. h1. DoD Write unit tests to show that MemoryMailboxChangesStore is functioning properly. -- 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-3457) Support JMAP PUSH
[ https://issues.apache.org/jira/browse/JAMES-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239554#comment-17239554 ] Lan Khuat commented on JAMES-3457: -- MailboxChangeRepository (memory version) implementation: https://issues.apache.org/jira/browse/JAMES-3459 > Support JMAP PUSH > - > > Key: JAMES-3457 > URL: https://issues.apache.org/jira/browse/JAMES-3457 > Project: James Server > Issue Type: Sub-task > Components: JMAP >Reporter: Benoit Tellier >Assignee: Antoine Duprat >Priority: Major > > https://github.com/iNPUTmice/jmap/issues/26 > That would be awesome to have James as one of the first implementors of the > JMAP RFC-8620 Push mechanism. -- 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-3459) Implement a MailboxChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239568#comment-17239568 ] Lan Khuat commented on JAMES-3459: -- https://github.com/linagora/james-project/pull/4088 > Implement a MailboxChangeRepository > --- > > Key: JAMES-3459 > URL: https://issues.apache.org/jira/browse/JAMES-3459 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > From the spec: [https://jmap.io/spec-core.html#changes] > ``` > When the state of the set of Foo records in an account changes on the server > (whether due to creation, updates, or deletion), the state property of the > Foo/get response will change. > ``` > We need to store all the changes made to mailbox objects in a table name > MailboxChangeRepository. First we will implement a memory version of it. > h1. How > * Define MailboxChange model. > * Define a contract for the MailboxChangeRepository. > * Implement MemoryMailboxChangeRepository APIs (save, getSinceState) base on > the contract. > h1. DoD > Write unit tests to show that MemoryMailboxChangesRepository is functioning > properly. -- 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] [Updated] (JAMES-3462) Implement CassandraMailboxChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3462: - Description: Same purpose with the MemoryMailboxChangeRepository, we now need to implement it in Cassandra. h1. How 1. Define a MailboxChange table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the CassandraMailboxChangeRepository APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the MailboxChangeStore is working properly. was: Same purpose with the MemoryMailboxChangeStore, we now need to implement it in Cassandra. h1. How 1. Define a MailboxChange table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the CassandraMailboxChangeStore APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the MailboxChangeStore is working properly. > Implement CassandraMailboxChangeRepository > -- > > Key: JAMES-3462 > URL: https://issues.apache.org/jira/browse/JAMES-3462 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the MemoryMailboxChangeRepository, we now need to implement > it in Cassandra. > h1. How > 1. Define a MailboxChange table with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > 2. Implement the CassandraMailboxChangeRepository APIs, based on the contract > that has already been defined. > h1. DoD > Write unit tests to show that the MailboxChangeStore is working properly. -- 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] [Updated] (JAMES-3462) Implement CassandraMailboxChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3462: - Summary: Implement CassandraMailboxChangeRepository (was: Implement CassandraMailboxChangeStore) > Implement CassandraMailboxChangeRepository > -- > > Key: JAMES-3462 > URL: https://issues.apache.org/jira/browse/JAMES-3462 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the MemoryMailboxChangeStore, we now need to implement it > in Cassandra. > h1. How > 1. Define a MailboxChange table with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > 2. Implement the CassandraMailboxChangeStore APIs, based on the contract that > has already been defined. > h1. DoD > Write unit tests to show that the MailboxChangeStore is working properly. -- 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-3460) Implement a JMAP MailboxChangeListener
Lan Khuat created JAMES-3460: Summary: Implement a JMAP MailboxChangeListener Key: JAMES-3460 URL: https://issues.apache.org/jira/browse/JAMES-3460 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat We need to implement a listener in order to track the changes made to objects whenever a JMAP operation complete successfully (create/update/destroy). h1. How * Define a MailboxChangesListener that implements MailboxListener. * This component will handle MailboxAdded, MailboxDeletion, MailboxRenamed, MailboxACLUpdated events, storing them as MailboxChange(s) in the MailboxChangeRepository. h1. DoD Integration tests to show that the listener is able to record all changes accurately in the MailboxChangesRepository. -- 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-3462) Implement CassandraMailboxChangeStore
Lan Khuat created JAMES-3462: Summary: Implement CassandraMailboxChangeStore Key: JAMES-3462 URL: https://issues.apache.org/jira/browse/JAMES-3462 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat Same purpose with the `MemoryMailboxChangeStore`, we now need to implement it in Cassandra. h1. How 1. Define a `MailboxChange` table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the `CassandraMailboxChangeStore` APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the `MailboxChangeStore` is working properly. -- 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] [Updated] (JAMES-3462) Implement CassandraMailboxChangeStore
[ https://issues.apache.org/jira/browse/JAMES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3462: - Description: Same purpose with the MemoryMailboxChangeStore, we now need to implement it in Cassandra. h1. How 1. Define a MailboxChange table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the CassandraMailboxChangeStore APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the MailboxChangeStore is working properly. was: Same purpose with the *MemoryMailboxChangeStore*, we now need to implement it in Cassandra. h1. How 1. Define a *MailboxChange* table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the *CassandraMailboxChangeStore* APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the *MailboxChangeStore* is working properly. > Implement CassandraMailboxChangeStore > - > > Key: JAMES-3462 > URL: https://issues.apache.org/jira/browse/JAMES-3462 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the MemoryMailboxChangeStore, we now need to implement it > in Cassandra. > h1. How > 1. Define a MailboxChange table with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > 2. Implement the CassandraMailboxChangeStore APIs, based on the contract that > has already been defined. > h1. DoD > Write unit tests to show that the MailboxChangeStore is working properly. -- 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] [Updated] (JAMES-3462) Implement CassandraMailboxChangeStore
[ https://issues.apache.org/jira/browse/JAMES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3462: - Description: Same purpose with the *MemoryMailboxChangeStore*, we now need to implement it in Cassandra. h1. How 1. Define a *MailboxChange* table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the *CassandraMailboxChangeStore* APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the *MailboxChangeStore* is working properly. was: Same purpose with the `MemoryMailboxChangeStore`, we now need to implement it in Cassandra. h1. How 1. Define a `MailboxChange` table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the `CassandraMailboxChangeStore` APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the `MailboxChangeStore` is working properly. > Implement CassandraMailboxChangeStore > - > > Key: JAMES-3462 > URL: https://issues.apache.org/jira/browse/JAMES-3462 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the *MemoryMailboxChangeStore*, we now need to implement it > in Cassandra. > h1. How > 1. Define a *MailboxChange* table with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > 2. Implement the *CassandraMailboxChangeStore* APIs, based on the contract > that has already been defined. > h1. DoD > Write unit tests to show that the *MailboxChangeStore* is working properly. -- 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-3465) Mailbox/changes updatedProperties handling
Lan Khuat created JAMES-3465: Summary: Mailbox/changes updatedProperties handling Key: JAMES-3465 URL: https://issues.apache.org/jira/browse/JAMES-3465 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat We need to distinguish Mailbox "counts" updates from others. We should have storage for "updated" distinct from "countUpdated" changes. -- 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-3461) Implement Mailbox/changes method and related contract tests
Lan Khuat created JAMES-3461:
Summary: Implement Mailbox/changes method and related contract
tests
Key: JAMES-3461
URL: https://issues.apache.org/jira/browse/JAMES-3461
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
The Foo/changes method allows a client to efficiently update the state of its
Foo cache to match the new state on the server.
{code}
h1. How
1. Write a serializer to deserialize/serialize Mailbox/changes request/response.
2. Implement Mailbox/changes method + tests.
h1. Example
*Request*
{code:java}
[[ "Mailbox/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"sinceState": "01"
}, "t0" ]]
{code}
*Response*
{code:java}
[[ "Mailbox/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"oldState": "01",
"newState": "02",
"hasMoreChanges": false,
"created": [ "1", "2" ],
"updated": [],
"destroyed": []
}, "t0" ]]
{code}
h1. DoD
Write integration tests to show that we can retrieve the changes to mailbox(es)
from a particular state.
--
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] [Updated] (JAMES-3464) Mailbox/set should handle ifInState
[
https://issues.apache.org/jira/browse/JAMES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3464:
-
Description:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
ifInState: This is a state string as returned by the Foo/get method
(representing the state of all objects of this type in the account). If
supplied, the string must match the current state; otherwise, the method will
be aborted and a stateMismatch error returned. If null, any changes will be
applied to the current state.
{code}
h1. How
When Email/set request is received, if the ifInState property is present we
need to compare it with the current Mailbox state stored in
MailboxChangeRepository.
* if mismatched, a stateMismatch error should be returned.
* if matched, all the changes in the request will be applied and should create
a new state, unless all the methodCalls in the request end up failing.
If the ifInState property is omitted then all the changes will be applied to
the current state.
h1. DoD
Integration tests to show that the Mailbox/set method can handle ifInState
property.
was:
>From spec: https://jmap.io/spec-core.html#set (section 5.3)
{code:java}
ifInState: This is a state string as returned by the Foo/get method
(representing the state of all objects of this type in the account). If
supplied, the string must match the current state; otherwise, the method will
be aborted and a stateMismatch error returned. If null, any changes will be
applied to the current state.
{code}
h1. How
When Email/set request is received, if the ifInState property is present we
need to compare it with the current Mailbox state stored in
MailboxChangeRepository.
- if mismatched, a stateMismatch error should be returned.
- if matched, all the changes in the request will be applied and should create
a new state, unless all the methodCalls in the request end up failing.
If the ifInState property is omitted then all the changes will be applied to
the current state.
h1. DoD
Integration tests to show that the Mailbox/set method can handle ifInState
property.
> Mailbox/set should handle ifInState
> ---
>
> Key: JAMES-3464
> URL: https://issues.apache.org/jira/browse/JAMES-3464
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
> {code:java}
> ifInState: This is a state string as returned by the Foo/get method
> (representing the state of all objects of this type in the account). If
> supplied, the string must match the current state; otherwise, the method will
> be aborted and a stateMismatch error returned. If null, any changes will be
> applied to the current state.
> {code}
> h1. How
> When Email/set request is received, if the ifInState property is present we
> need to compare it with the current Mailbox state stored in
> MailboxChangeRepository.
> * if mismatched, a stateMismatch error should be returned.
> * if matched, all the changes in the request will be applied and should
> create a new state, unless all the methodCalls in the request end up failing.
> If the ifInState property is omitted then all the changes will be applied to
> the current state.
> h1. DoD
> Integration tests to show that the Mailbox/set method can handle ifInState
> property.
--
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-3464) Mailbox/set should handle ifInState
Lan Khuat created JAMES-3464:
Summary: Mailbox/set should handle ifInState
Key: JAMES-3464
URL: https://issues.apache.org/jira/browse/JAMES-3464
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From spec: https://jmap.io/spec-core.html#set (section 5.3)
{code:java}
ifInState: This is a state string as returned by the Foo/get method
(representing the state of all objects of this type in the account). If
supplied, the string must match the current state; otherwise, the method will
be aborted and a stateMismatch error returned. If null, any changes will be
applied to the current state.
{code}
h1. How
When Email/set request is received, if the ifInState property is present we
need to compare it with the current Mailbox state stored in
MailboxChangeRepository.
- if mismatched, a stateMismatch error should be returned.
- if matched, all the changes in the request will be applied and should create
a new state, unless all the methodCalls in the request end up failing.
If the ifInState property is omitted then all the changes will be applied to
the current state.
h1. DoD
Integration tests to show that the Mailbox/set method can handle ifInState
property.
--
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-3463) Mailbox/get should handle state property
Lan Khuat created JAMES-3463:
Summary: Mailbox/get should handle state property
Key: JAMES-3463
URL: https://issues.apache.org/jira/browse/JAMES-3463
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From spec: https://jmap.io/spec-core.html#get (section 5.1)
{code:java}
State: A string representing the state on the server for all the data of this
type in the account (not just the objects returned in this call). If the data
changes, this string MUST change. If the data is unchanged, servers SHOULD
return the same state string on subsequent requests.
{code}
h1. How
Whenever a Mailbox/get request is received, we need to fetch the most recent
state of Mailbox objects stored in the MailboxChangeRepository and return it in
the response.
h1. DoD
Integration tests to show that Mailbox/get method can handle the state property.
--
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] [Updated] (JAMES-3464) Mailbox/set should handle oldState & newState
[
https://issues.apache.org/jira/browse/JAMES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3464:
-
Description:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
* When a Mailbox/set request is received, we need to fetch the current state
of the Mailbox objects. This should be returned as `oldState` property in the
response.
* After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
MailboxChangeRepository and return it with the response as `newState` property.
* If all the methodCalls in the request end up failing then no new state
should be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
was:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
- When a Mailbox/set request is received, we need to fetch the current state of
the Mailbox objects. This should be returned as `oldState` property in the
response.
- After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
MailboxChangeRepository and return it with the response as `newState` property.
- If all the methodCalls in the request end up failing then no new state should
be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
> Mailbox/set should handle oldState & newState
> -
>
> Key: JAMES-3464
> URL: https://issues.apache.org/jira/browse/JAMES-3464
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
> {code:java}
> oldState: The state string that would have been returned by Foo/get before
> making the requested changes, or null if the server doesn’t know what the
> previous state string was.
> newState: The state string that will now be returned by Foo/get.
> {code}
> h1. How
> * When a Mailbox/set request is received, we need to fetch the current state
> of the Mailbox objects. This should be returned as `oldState` property in the
> response.
> * After all the changes in the Mailbox/set request have been applied
> successfully, we should create a new state, store it in the
> MailboxChangeRepository and return it with the response as `newState`
> property.
> * If all the methodCalls in the request end up failing then no new state
> should be generated.
> h1. DoD
> Integration tests to show that the Mailbox/set method can return oldState &
> newState property.
--
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] [Updated] (JAMES-3464) Mailbox/set should handle oldState & newState
[
https://issues.apache.org/jira/browse/JAMES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3464:
-
Description:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
* When a Mailbox/set request is received, we need to fetch the current state
of the Mailbox objects. This should be returned as the *oldState* property in
the response.
* After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
MailboxChangeRepository and return it with the response as the *newState*
property.
* If all the methodCalls in the request end up failing then no new state
should be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
was:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
* When a Mailbox/set request is received, we need to fetch the current state
of the Mailbox objects. This should be returned as `oldState` property in the
response.
* After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
MailboxChangeRepository and return it with the response as `newState` property.
* If all the methodCalls in the request end up failing then no new state
should be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
> Mailbox/set should handle oldState & newState
> -
>
> Key: JAMES-3464
> URL: https://issues.apache.org/jira/browse/JAMES-3464
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
> {code:java}
> oldState: The state string that would have been returned by Foo/get before
> making the requested changes, or null if the server doesn’t know what the
> previous state string was.
> newState: The state string that will now be returned by Foo/get.
> {code}
> h1. How
> * When a Mailbox/set request is received, we need to fetch the current state
> of the Mailbox objects. This should be returned as the *oldState* property in
> the response.
> * After all the changes in the Mailbox/set request have been applied
> successfully, we should create a new state, store it in the
> MailboxChangeRepository and return it with the response as the *newState*
> property.
> * If all the methodCalls in the request end up failing then no new state
> should be generated.
> h1. DoD
> Integration tests to show that the Mailbox/set method can return oldState &
> newState property.
--
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] [Updated] (JAMES-3464) Mailbox/set should handle oldState & newState
[
https://issues.apache.org/jira/browse/JAMES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3464:
-
Description:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
- When a Mailbox/set request is received, we need to fetch the current state of
the Mailbox objects. This should be returned as `oldState` property in the
response.
- After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
MailboxChangeRepository and return it with the response as `newState` property.
- If all the methodCalls in the request end up failing then no new state should
be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
was:
>From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
{code:java}
ifInState: This is a state string as returned by the Foo/get method
(representing the state of all objects of this type in the account). If
supplied, the string must match the current state; otherwise, the method will
be aborted and a stateMismatch error returned. If null, any changes will be
applied to the current state.
{code}
h1. How
When Email/set request is received, if the ifInState property is present we
need to compare it with the current Mailbox state stored in
MailboxChangeRepository.
* if mismatched, a stateMismatch error should be returned.
* if matched, all the changes in the request will be applied and should create
a new state, unless all the methodCalls in the request end up failing.
If the ifInState property is omitted then all the changes will be applied to
the current state.
h1. DoD
Integration tests to show that the Mailbox/set method can handle ifInState
property.
Summary: Mailbox/set should handle oldState & newState (was:
Mailbox/set should handle ifInState)
> Mailbox/set should handle oldState & newState
> -
>
> Key: JAMES-3464
> URL: https://issues.apache.org/jira/browse/JAMES-3464
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
> {code:java}
> oldState: The state string that would have been returned by Foo/get before
> making the requested changes, or null if the server doesn’t know what the
> previous state string was.
> newState: The state string that will now be returned by Foo/get.
> {code}
> h1. How
> - When a Mailbox/set request is received, we need to fetch the current state
> of the Mailbox objects. This should be returned as `oldState` property in the
> response.
> - After all the changes in the Mailbox/set request have been applied
> successfully, we should create a new state, store it in the
> MailboxChangeRepository and return it with the response as `newState`
> property.
> - If all the methodCalls in the request end up failing then no new state
> should be generated.
>
> h1. DoD
> Integration tests to show that the Mailbox/set method can return oldState &
> newState property.
--
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-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240664#comment-17240664 ] Lan Khuat commented on JAMES-2884: -- Hi everyone, I'm Lan, a developer of the Apache James project. In the coming month, i will be working on the JMAP Push for James, starting with a POC for the Mailbox/changes part. First we want to have a repository to track all the changes made to Mailbox objects, in memory implemented. See: https://issues.apache.org/jira/browse/JAMES-3459 You can take a look at the PR which handle the aforementioned ticket here: [https://github.com/linagora/james-project/pull/4088 |https://github.com/linagora/james-project/pull/4088] Tickets need to be handled: * Implement a MailboxChangeListener: https://issues.apache.org/jira/browse/JAMES-3460 * Implement Mailbox/changes method: https://issues.apache.org/jira/browse/JAMES-3461 * Cassandra version of the MailboxChangeRepository: https://issues.apache.org/jira/browse/JAMES-3462 * *state* property handling: https://issues.apache.org/jira/browse/JAMES-3463 * *oldState* & *newState* handling: https://issues.apache.org/jira/browse/JAMES-3464 * differentiate changes between a Mailbox and messages belong to it: https://issues.apache.org/jira/browse/JAMES-3465 > Update JMAP implementation to conform to RFC 8620/8621 > -- > > Key: JAMES-2884 > URL: https://issues.apache.org/jira/browse/JAMES-2884 > Project: James Server > Issue Type: Improvement > Components: JMAP >Reporter: cketti >Assignee: Antoine Duprat >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > Historically, James is an early adopter for the JMAP specification, and a > first partial implementation was conducted when JMAP was just a draft. IETF > draft undergo radical changes and the community could not keep this > implementation up to date with the spec changes. > As off summer 2019, JMAP core ([RFC > 8620|https://tools.ietf.org/html/rfc8620]) and JMAP mail ([RFC > 8621|https://tools.ietf.org/html/rfc8621]) had been officially published > (will not change anymore). Thus we should implement these new specifications. > Point of attention: part of the community actively rely on the actual 'draft' > implementation of JMAP existing in James. We should ensure no changes is done > to that 'draft' protocol is done while implementing the new one. > The proposed approach is to keep the current implementation under the > `jmap-draft` name, and implement step by step a `jmap` compliant > implementation, that will be exposed on a separate port. No modification in > `jmap-draft` integration test should be counducted. > This will allow existing `jmap-draft` clients to smoothly transition to > `jmap`, then trigger the classic "deprecation-then-removal" process. > For now, as a first implementation step, we will only support `jmap` on top > of memory-guice (ease testing, speed of development). To ensure a > `storage-compliant` behavior of newly introduced storage APIs, we should use > persistent datastructures (like the one in vavr) and always deep-copy objects > at the storage boundaries. -- 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-3464) Mailbox/set should handle oldState & newState
[
https://issues.apache.org/jira/browse/JAMES-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240657#comment-17240657
]
Lan Khuat commented on JAMES-3464:
--
Sorry i was mistaken. Description fixed now.
> Mailbox/set should handle oldState & newState
> -
>
> Key: JAMES-3464
> URL: https://issues.apache.org/jira/browse/JAMES-3464
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From spec: [https://jmap.io/spec-core.html#set] (section 5.3)
> {code:java}
> oldState: The state string that would have been returned by Foo/get before
> making the requested changes, or null if the server doesn’t know what the
> previous state string was.
> newState: The state string that will now be returned by Foo/get.
> {code}
> h1. How
> * When a Mailbox/set request is received, we need to fetch the current state
> of the Mailbox objects. This should be returned as the *oldState* property in
> the response.
> * After all the changes in the Mailbox/set request have been applied
> successfully, we should create a new state, store it in the
> MailboxChangeRepository and return it with the response as the *newState*
> property.
> * If all the methodCalls in the request end up failing then no new state
> should be generated.
> h1. DoD
> Integration tests to show that the Mailbox/set method can return oldState &
> newState property.
--
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] [Updated] (JAMES-3462) Implement CassandraMailboxChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3462: - Description: Same purpose with the MemoryMailboxChangeRepository, we now need to implement it in Cassandra. h1. How 1. Define a MailboxChange table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the CassandraMailboxChangeRepository APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the MailboxChangeRepository is working properly. was: Same purpose with the MemoryMailboxChangeRepository, we now need to implement it in Cassandra. h1. How 1. Define a MailboxChange table with these fields: - accountId - state - created - updated - destroyed - date 2. Implement the CassandraMailboxChangeRepository APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the MailboxChangeStore is working properly. > Implement CassandraMailboxChangeRepository > -- > > Key: JAMES-3462 > URL: https://issues.apache.org/jira/browse/JAMES-3462 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the MemoryMailboxChangeRepository, we now need to implement > it in Cassandra. > h1. How > 1. Define a MailboxChange table with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > 2. Implement the CassandraMailboxChangeRepository APIs, based on the contract > that has already been defined. > h1. DoD > Write unit tests to show that the MailboxChangeRepository is working properly. -- 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-3469) Implement MemoryEmailChangeRepository
Lan Khuat created JAMES-3469: Summary: Implement MemoryEmailChangeRepository Key: JAMES-3469 URL: https://issues.apache.org/jira/browse/JAMES-3469 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat h1. Objective >From the spec: https://jmap.io/spec-core.html#changes ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name EmailChangeRepository. First we will implement a memory version of it. h1. How 1. Define EmailChange model with these fields: - accountId - state - created - updated - destroyed - date 2. Implement APIs to interact with MemoryEmailChangeRepository (save, getFromState) h1. DoD Write unit tests to show that MemoryEmailChangeRepository is functioning properly. -- 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] [Updated] (JAMES-3469) Implement MemoryEmailChangeRepository
[
https://issues.apache.org/jira/browse/JAMES-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3469:
-
Description:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
{code}
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
* accountId
* state
* created
* updated
* destroyed
* date
2. Implement APIs to interact with MemoryEmailChangeRepository (save,
getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
was:
>From the spec: [https://jmap.io/spec-core.html#changes]
```
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
```
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
- accountId
- state
- created
- updated
- destroyed
- date
Implement APIs to interact with MemoryEmailChangeRepository (save, getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
> Implement MemoryEmailChangeRepository
> -
>
> Key: JAMES-3469
> URL: https://issues.apache.org/jira/browse/JAMES-3469
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From the spec: [https://jmap.io/spec-core.html#changes]
>
> {code:java}
> When the state of the set of Foo records in an account changes on the server
> (whether due to creation, updates, or deletion), the state property of the
> Foo/get response will change.
> {code}
> We need to store all the changes made to mailbox objects in a table name
> EmailChangeRepository. First we will implement a memory version of it.
>
> h1. How
> 1. Define EmailChange model with these fields:
> * accountId
> * state
> * created
> * updated
> * destroyed
> * date
> 2. Implement APIs to interact with MemoryEmailChangeRepository (save,
> getFromState)
> h1. DoD
> Write unit tests to show that MemoryEmailChangeRepository is functioning
> properly.
>
--
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] [Updated] (JAMES-3469) Implement MemoryEmailChangeRepository
[
https://issues.apache.org/jira/browse/JAMES-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3469:
-
Description:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
{code}
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
* accountId
* state
* created
* updated
* destroyed
* date
2. Implement APIs to interact with MemoryEmailChangeRepository (save,
getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
was:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
{code}
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
* accountId
* state
* created
* updated
* destroyed
* date
2. Implement APIs to interact with MemoryEmailChangeRepository (save,
getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
> Implement MemoryEmailChangeRepository
> -
>
> Key: JAMES-3469
> URL: https://issues.apache.org/jira/browse/JAMES-3469
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From the spec: [https://jmap.io/spec-core.html#changes]
> {code:java}
> When the state of the set of Foo records in an account changes on the server
> (whether due to creation, updates, or deletion), the state property of the
> Foo/get response will change.
> {code}
> We need to store all the changes made to mailbox objects in a table name
> EmailChangeRepository. First we will implement a memory version of it.
> h1. How
> 1. Define EmailChange model with these fields:
> * accountId
> * state
> * created
> * updated
> * destroyed
> * date
> 2. Implement APIs to interact with MemoryEmailChangeRepository (save,
> getFromState)
> h1. DoD
> Write unit tests to show that MemoryEmailChangeRepository is functioning
> properly.
>
--
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] [Updated] (JAMES-3469) Implement MemoryEmailChangeRepository
[
https://issues.apache.org/jira/browse/JAMES-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3469:
-
Description:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
{code}
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
* accountId
* state
* created
* updated
* destroyed
* date
2. Implement APIs to interact with MemoryEmailChangeRepository (save,
getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
was:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
When the state of the set of Foo records in an account changes on the server
(whether due to creation, updates, or deletion), the state property of the
Foo/get response will change.
{code}
We need to store all the changes made to mailbox objects in a table name
EmailChangeRepository. First we will implement a memory version of it.
h1. How
1. Define EmailChange model with these fields:
* accountId
* state
* created
* updated
* destroyed
* date
2. Implement APIs to interact with MemoryEmailChangeRepository (save,
getFromState)
h1. DoD
Write unit tests to show that MemoryEmailChangeRepository is functioning
properly.
> Implement MemoryEmailChangeRepository
> -
>
> Key: JAMES-3469
> URL: https://issues.apache.org/jira/browse/JAMES-3469
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From the spec: [https://jmap.io/spec-core.html#changes]
>
> {code:java}
> When the state of the set of Foo records in an account changes on the server
> (whether due to creation, updates, or deletion), the state property of the
> Foo/get response will change.
> {code}
> We need to store all the changes made to mailbox objects in a table name
> EmailChangeRepository. First we will implement a memory version of it.
> h1. How
> 1. Define EmailChange model with these fields:
> * accountId
> * state
> * created
> * updated
> * destroyed
> * date
> 2. Implement APIs to interact with MemoryEmailChangeRepository (save,
> getFromState)
> h1. DoD
> Write unit tests to show that MemoryEmailChangeRepository is functioning
> properly.
>
--
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-3471) MailboxChangeListener needs to handle EmailChange events
Lan Khuat created JAMES-3471: Summary: MailboxChangeListener needs to handle EmailChange events Key: JAMES-3471 URL: https://issues.apache.org/jira/browse/JAMES-3471 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat Update MailboxChangeListener so that it can record events related to Email objects and store them accordingly. h1. How Beside MailboxChangeRepository, MailboxChangeListener should rely also on EmailChangeRepository to store the changes for Email objects. h1. DoD Unit tests to show that MailboxListener can store changes in the EmailChangeRepository properly. -- 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-3473) Email/get should handle state property
Lan Khuat created JAMES-3473:
Summary: Email/get should handle state property
Key: JAMES-3473
URL: https://issues.apache.org/jira/browse/JAMES-3473
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From spec: https://jmap.io/spec-core.html#get (section 5.1)
{code:java}
State: A string representing the state on the server for all the data of this
type in the account (not just the objects returned in this call). If the data
changes, this string MUST change. If the data is unchanged, servers SHOULD
return the same state string on subsequent requests.
{code}
h1. How
Whenever a Email/get request is received, we need to fetch the most recent
state of Email objects stored in the EmailChangeRepository and return it in the
response.
h1. DoD
Integration tests to show that Email/get method can handle the `state` property.
--
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-3470) Implement CassandraEmailChangeStore
Lan Khuat created JAMES-3470: Summary: Implement CassandraEmailChangeStore Key: JAMES-3470 URL: https://issues.apache.org/jira/browse/JAMES-3470 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat Same purpose with the MemoryEmailChangeStore, we now need to implement it in Cassandra. h1. How 1. Define a EmailChange table with these fields: * accountId * state * created * updated * destroyed * date 2. Implement the CassandraEmailChangeStore APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the EmailChangeStore is working properly. -- 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] [Updated] (JAMES-3470) Implement CassandraEmailChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3470: - Description: Same purpose with the MemoryEmailChangeRepository, we now need to implement it in Cassandra. h1. How 1. Define a EmailChange table with these fields: * accountId * state * created * updated * destroyed * date 2. Implement the CassandraEmailChangeRepository APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the EmailChangeRepository is working properly. was: Same purpose with the MemoryEmailChangeStore, we now need to implement it in Cassandra. h1. How 1. Define a EmailChange table with these fields: * accountId * state * created * updated * destroyed * date 2. Implement the CassandraEmailChangeStore APIs, based on the contract that has already been defined. h1. DoD Write unit tests to show that the EmailChangeStore is working properly. Summary: Implement CassandraEmailChangeRepository (was: Implement CassandraEmailChangeStore) > Implement CassandraEmailChangeRepository > > > Key: JAMES-3470 > URL: https://issues.apache.org/jira/browse/JAMES-3470 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > Same purpose with the MemoryEmailChangeRepository, we now need to implement > it in Cassandra. > h1. How > 1. Define a EmailChange table with these fields: > * accountId > * state > * created > * updated > * destroyed > * date > 2. Implement the CassandraEmailChangeRepository APIs, based on the contract > that has already been defined. > h1. DoD > Write unit tests to show that the EmailChangeRepository is working properly. -- 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] [Updated] (JAMES-3469) Implement MemoryEmailChangeRepository
[ https://issues.apache.org/jira/browse/JAMES-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3469: - Description: >From the spec: [https://jmap.io/spec-core.html#changes] ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name EmailChangeRepository. First we will implement a memory version of it. h1. How 1. Define EmailChange model with these fields: - accountId - state - created - updated - destroyed - date Implement APIs to interact with MemoryEmailChangeRepository (save, getFromState) h1. DoD Write unit tests to show that MemoryEmailChangeRepository is functioning properly. was: h1. Objective >From the spec: https://jmap.io/spec-core.html#changes ``` When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the state property of the Foo/get response will change. ``` We need to store all the changes made to mailbox objects in a table name EmailChangeRepository. First we will implement a memory version of it. h1. How 1. Define EmailChange model with these fields: - accountId - state - created - updated - destroyed - date 2. Implement APIs to interact with MemoryEmailChangeRepository (save, getFromState) h1. DoD Write unit tests to show that MemoryEmailChangeRepository is functioning properly. > Implement MemoryEmailChangeRepository > - > > Key: JAMES-3469 > URL: https://issues.apache.org/jira/browse/JAMES-3469 > Project: James Server > Issue Type: Sub-task >Reporter: Lan Khuat >Priority: Major > > From the spec: [https://jmap.io/spec-core.html#changes] > ``` > When the state of the set of Foo records in an account changes on the server > (whether due to creation, updates, or deletion), the state property of the > Foo/get response will change. > ``` > We need to store all the changes made to mailbox objects in a table name > EmailChangeRepository. First we will implement a memory version of it. > h1. How > 1. Define EmailChange model with these fields: > - accountId > - state > - created > - updated > - destroyed > - date > Implement APIs to interact with MemoryEmailChangeRepository (save, > getFromState) > h1. DoD > Write unit tests to show that MemoryEmailChangeRepository is functioning > properly. > -- 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-3472) Implement Email/changes method and related contract tests
Lan Khuat created JAMES-3472:
Summary: Implement Email/changes method and related contract tests
Key: JAMES-3472
URL: https://issues.apache.org/jira/browse/JAMES-3472
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
The Foo/changes method allows a client to efficiently update the state of its
Foo cache to match the new state on the server. {code}
h1. How
Serializer to deserialize/serialize Email/changes request/response has already
been written with Mailbox/changes implementation. We now only need to implement
Email/changes method + tests.
h1. Example
**Request**
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"sinceState": "01"
}, "t0" ]]
{code}
**Response**
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"oldState": "01",
"newState": "02",
"hasMoreChanges": false,
"created": [ "1", "2" ],
"updated": [],
"destroyed": []
}, "t0" ]]
{code}
h1. DoD
Write integration tests to show that we can retrieve the changes to email(s)
from a particular state.
--
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] [Updated] (JAMES-3472) Implement Email/changes method and related contract tests
[
https://issues.apache.org/jira/browse/JAMES-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3472:
-
Description:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
The Foo/changes method allows a client to efficiently update the state of its
Foo cache to match the new state on the server. {code}
h1. How
Serializer to deserialize/serialize Email/changes request/response has already
been written with Mailbox/changes implementation. We now only need to implement
Email/changes method + tests.
h1. Example
*Request*
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"sinceState": "01"
}, "t0" ]]
{code}
*Response*
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"oldState": "01",
"newState": "02",
"hasMoreChanges": false,
"created": [ "1", "2" ],
"updated": [],
"destroyed": []
}, "t0" ]]
{code}
h1. DoD
Write integration tests to show that we can retrieve the changes to email(s)
from a particular state.
was:
>From the spec: [https://jmap.io/spec-core.html#changes]
{code:java}
The Foo/changes method allows a client to efficiently update the state of its
Foo cache to match the new state on the server. {code}
h1. How
Serializer to deserialize/serialize Email/changes request/response has already
been written with Mailbox/changes implementation. We now only need to implement
Email/changes method + tests.
h1. Example
**Request**
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"sinceState": "01"
}, "t0" ]]
{code}
**Response**
{code:java}
[[ "Email/changes", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"oldState": "01",
"newState": "02",
"hasMoreChanges": false,
"created": [ "1", "2" ],
"updated": [],
"destroyed": []
}, "t0" ]]
{code}
h1. DoD
Write integration tests to show that we can retrieve the changes to email(s)
from a particular state.
> Implement Email/changes method and related contract tests
> -
>
> Key: JAMES-3472
> URL: https://issues.apache.org/jira/browse/JAMES-3472
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> From the spec: [https://jmap.io/spec-core.html#changes]
> {code:java}
> The Foo/changes method allows a client to efficiently update the state of its
> Foo cache to match the new state on the server. {code}
> h1. How
> Serializer to deserialize/serialize Email/changes request/response has
> already been written with Mailbox/changes implementation. We now only need to
> implement Email/changes method + tests.
> h1. Example
> *Request*
> {code:java}
> [[ "Email/changes", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "sinceState": "01"
> }, "t0" ]]
> {code}
>
> *Response*
> {code:java}
> [[ "Email/changes", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "oldState": "01",
> "newState": "02",
> "hasMoreChanges": false,
> "created": [ "1", "2" ],
> "updated": [],
> "destroyed": []
> }, "t0" ]]
> {code}
> h1. DoD
> Write integration tests to show that we can retrieve the changes to email(s)
> from a particular state.
--
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-3474) Email/set should handle oldState & newState
Lan Khuat created JAMES-3474:
Summary: Email/set should handle oldState & newState
Key: JAMES-3474
URL: https://issues.apache.org/jira/browse/JAMES-3474
Project: James Server
Issue Type: Sub-task
Reporter: Lan Khuat
>From spec: https://jmap.io/spec-core.html#set (section 5.3)
{code:java}
oldState: The state string that would have been returned by Foo/get before
making the requested changes, or null if the server doesn’t know what the
previous state string was.
newState: The state string that will now be returned by Foo/get.
{code}
h1. How
- When a Email/set request is received, we need to fetch the current state of
the Email objects. This should be returned as `oldState` property in the
response.
- After all the changes in the Mailbox/set request have been applied
successfully, we should create a new state, store it in the
EmailChangeRepository and return it with the response as `newState` property.
- If all the methodCalls in the request end up failing then no new state should
be generated.
h1. DoD
Integration tests to show that the Mailbox/set method can return oldState &
newState property.
--
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-3481) Mailbox/changes should handle delegated mailbox
Lan Khuat created JAMES-3481: Summary: Mailbox/changes should handle delegated mailbox Key: JAMES-3481 URL: https://issues.apache.org/jira/browse/JAMES-3481 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat We should be able to store changes for user with access to a delegated mailbox. Also when fetching changes via Mailbox/changes, we should have an extension to decide whether to return "delegated changes" to the user or not. h3. How * Modified the MailboxChangeListener so that when an mailbox event occur, it can record multiple changes for all users who currently having access to that mailbox. * Add a field to MailboxChange object in order to differentiate between normal/delegated changes. * Use *Shares* capability to filter out delegated changes. h3. DoD * Unit tests in MailboxChangeRepository, MailboxChangeListener * Integration tests to show that we can filter out delegated changes. -- 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-3439) Email/set create specify attachments
Lan Khuat created JAMES-3439:
Summary: Email/set create specify attachments
Key: JAMES-3439
URL: https://issues.apache.org/jira/browse/JAMES-3439
Project: James Server
Issue Type: Bug
Reporter: Lan Khuat
As a user i want to add attachments when creating an email draft.
Example
Request
{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",
"attachments": [
{
"blobId": "vuebziouvbher",
"type":"text/plain",
"charset":"UTF-8",
"disposition": "attachment",
"language": ["fr"],
"location": ["http://125.26.23.36/content;]
}
]
}
}
}, "0" ]]
{code}
Response (with Email/get)
{code:java}
"methodResponses": [[
"Email/get",
{
"mailboxIds": {
"1": true
},
"subject": "World domination",
"attachments": [
{
"partId": "3",
"blobId": "$blobIdToDownload",
"size": 11,
"type": "text/plain",
"charset": "UTF-8",
"disposition": "attachment",
"language": ["fr", "en"],
"location": "http://125.26.23.36/content;
}
]
}, "0"
]]
{code}
--
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] [Updated] (JAMES-3439) Email/set create specify attachments
[
https://issues.apache.org/jira/browse/JAMES-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3439:
-
Description:
As a user i want to add attachments when creating an email draft. This
including:
* normal attachments (multipart/mixed)
* inline attachments (multipart/related)
*Example*
*Request*
{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",
"attachments": [
{
"blobId": "vuebziouvbher",
"type":"text/plain",
"charset":"UTF-8",
"disposition": "attachment",
"language": ["fr"],
"location": ["http://125.26.23.36/content;]
}
]
}
}
}, "0" ]]
{code}
*Response (with Email/get)*
{code:java}
"methodResponses": [[
"Email/get",
{
"mailboxIds": {
"1": true
},
"subject": "World domination",
"attachments": [
{
"partId": "3",
"blobId": "$blobIdToDownload",
"size": 11,
"type": "text/plain",
"charset": "UTF-8",
"disposition": "attachment",
"language": ["fr", "en"],
"location": "http://125.26.23.36/content;
}
]
}, "0"
]]
{code}
was:
As a user i want to add attachments when creating an email draft.
Example
Request
{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",
"attachments": [
{
"blobId": "vuebziouvbher",
"type":"text/plain",
"charset":"UTF-8",
"disposition": "attachment",
"language": ["fr"],
"location": ["http://125.26.23.36/content;]
}
]
}
}
}, "0" ]]
{code}
Response (with Email/get)
{code:java}
"methodResponses": [[
"Email/get",
{
"mailboxIds": {
"1": true
},
"subject": "World domination",
"attachments": [
{
"partId": "3",
"blobId": "$blobIdToDownload",
"size": 11,
"type": "text/plain",
"charset": "UTF-8",
"disposition": "attachment",
"language": ["fr", "en"],
"location": "http://125.26.23.36/content;
}
]
}, "0"
]]
{code}
> Email/set create specify attachments
>
>
> Key: JAMES-3439
> URL: https://issues.apache.org/jira/browse/JAMES-3439
> Project: James Server
> Issue Type: Bug
>Reporter: Lan Khuat
>Priority: Major
>
> As a user i want to add attachments when creating an email draft. This
> including:
> * normal attachments (multipart/mixed)
> * inline attachments (multipart/related)
> *Example*
> *Request*
> {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",
> "attachments": [
> {
> "blobId": "vuebziouvbher",
> "type":"text/plain",
> "charset":"UTF-8",
> "disposition": "attachment",
> "language": ["fr"],
> "location": ["http://125.26.23.36/content;]
> }
> ]
> }
> }
> }, "0" ]]
> {code}
>
> *Response (with Email/get)*
>
> {code:java}
> "methodResponses": [[
> "Email/get",
> {
> "mailboxIds": {
> "1": true
> },
> "subject": "World domination",
> "attachments": [
> {
> "partId": "3",
> "blobId": "$blobIdToDownload",
> "size": 11,
> "type": "text/plain",
> "charset": "UTF-8",
> "disposition": "attachment",
> "language": ["fr", "en"],
> "location": "http://125.26.23.36/content;
> }
> ]
> }, "0"
> ]]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For
[jira] [Updated] (JAMES-3442) Email/set create position multipart/alternative for text/html body
[ https://issues.apache.org/jira/browse/JAMES-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3442: - Description: In order to support mail client that cannot display *html*, we need to extract the text parts from email body as *text/plain* and put both *text/html* and *text/plain* in a *multipart/alternative* EmailBodyPart. (was: In order to support mail client that cannot display html, we need to extract the text parts from email body as text/plain and put both `text/html` and `text/plain` in a `multipart/alternative` EmailBodyPart.) > Email/set create position multipart/alternative for text/html body > -- > > Key: JAMES-3442 > URL: https://issues.apache.org/jira/browse/JAMES-3442 > Project: James Server > Issue Type: Bug >Reporter: Lan Khuat >Priority: Major > > In order to support mail client that cannot display *html*, we need to > extract the text parts from email body as *text/plain* and put both > *text/html* and *text/plain* in a *multipart/alternative* EmailBodyPart. -- 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-3442) Email/set create position multipart/alternative for text/html body
Lan Khuat created JAMES-3442: Summary: Email/set create position multipart/alternative for text/html body Key: JAMES-3442 URL: https://issues.apache.org/jira/browse/JAMES-3442 Project: James Server Issue Type: Bug Reporter: Lan Khuat In order to support mail client that cannot display html, we need to extract the text parts from email body as text/plain and put both `text/html` and `text/plain` in a `multipart/alternative` EmailBodyPart. -- 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-3445) Document Email/set create / update / destroy
Lan Khuat created JAMES-3445: Summary: Document Email/set create / update / destroy Key: JAMES-3445 URL: https://issues.apache.org/jira/browse/JAMES-3445 Project: James Server Issue Type: Improvement Reporter: Lan Khuat Since JMAP RFC-8621 has been partially implemented, we need to update the documentation about Email/set create/update/destroy accordingly. -- 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-3447) Email/set create should return blobId, threadId, size
Lan Khuat created JAMES-3447:
Summary: Email/set create should return blobId, threadId, size
Key: JAMES-3447
URL: https://issues.apache.org/jira/browse/JAMES-3447
Project: James Server
Issue Type: Bug
Reporter: Lan Khuat
According to spec: [https://jmap.io/spec-mail.html]
{code:java}
For successfully copied Email objects, the created response contains the id,
blobId, threadId, and size properties of the new object.
{code}
--
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-3450) Email/query reject Filter object with both FilterOperator and FilterCondition
[
https://issues.apache.org/jira/browse/JAMES-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234414#comment-17234414
]
Lan Khuat commented on JAMES-3450:
--
Descriptions added.
> Email/query reject Filter object with both FilterOperator and FilterCondition
> -
>
> Key: JAMES-3450
> URL: https://issues.apache.org/jira/browse/JAMES-3450
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5,
> a filter object in Email/query can either be an array of FilterOperator or
> FilterCondition.
> Currently we are allowing the request to have properties from both types.
> This could lead to unexpected result when querying Email. For example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/query", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "filter": {
> "inMailbox": "1",
> "operator": "AND",
> "conditions": [
> { "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
> ]
> }
> }, "c1"]
> ]
> }
> {code}
> Email/query will ignore the _*inMailbox*_ condition in the request above.
> *DoD*
> Integration tests to show that Email/query only accept an array of
> FilterOperator or FilterCondition in their respective correct structure.
--
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] [Comment Edited] (JAMES-3450) Email/query reject Filter object with both FilterOperator and FilterCondition
[
https://issues.apache.org/jira/browse/JAMES-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234414#comment-17234414
]
Lan Khuat edited comment on JAMES-3450 at 11/18/20, 9:26 AM:
-
Description added.
was (Author: dlkhuat):
Descriptions added.
> Email/query reject Filter object with both FilterOperator and FilterCondition
> -
>
> Key: JAMES-3450
> URL: https://issues.apache.org/jira/browse/JAMES-3450
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5,
> a filter object in Email/query can either be an array of FilterOperator or
> FilterCondition.
> Currently we are allowing the request to have properties from both types.
> This could lead to unexpected result when querying Email. For example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/query", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "filter": {
> "inMailbox": "1",
> "operator": "AND",
> "conditions": [
> { "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
> ]
> }
> }, "c1"]
> ]
> }
> {code}
> Email/query will ignore the _*inMailbox*_ condition in the request above.
> *DoD*
> Integration tests to show that Email/query only accept an array of
> FilterOperator or FilterCondition in their respective correct structure.
--
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] [Updated] (JAMES-3450) Email/query reject Filter object with both FilterOperator and FilterCondition
[
https://issues.apache.org/jira/browse/JAMES-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3450:
-
Description:
According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5, a
filter object in Email/query can either be an array of FilterOperator or
FilterCondition.
Currently we are allowing the request to have properties from both types. This
could lead to unexpected result when querying Email. For example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/query", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"filter": {
"inMailbox": "1",
"operator": "AND",
"conditions": [
{ "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
]
}
}, "c1"]
]
}
{code}
Email/query will ignore the _*inMailbox*_ condition in the request above.
*DoD*
Integration tests to show that Email/query only accept an array of
FilterOperator or FilterCondition in their respective correct structure.
was:
According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5, a
filter object in Email/query can either be an array of FilterOperator or
FilterCondition.
Currently we are allowing the request to have properties from both types. This
could lead to unexpected result when querying Email. For example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/query", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"filter": {
"inMailbox": "1",
"operator": "AND",
"conditions": [
{ "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
]
}
}, "c1"]
]
}
{code}
Email/query will ignore the `inMailbox` condition in the request above.
*DoD*
Integration tests to show that Email/query only accept an array of
FilterOperator or FilterCondition in their respective correct structure.
> Email/query reject Filter object with both FilterOperator and FilterCondition
> -
>
> Key: JAMES-3450
> URL: https://issues.apache.org/jira/browse/JAMES-3450
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5,
> a filter object in Email/query can either be an array of FilterOperator or
> FilterCondition.
> Currently we are allowing the request to have properties from both types.
> This could lead to unexpected result when querying Email. For example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/query", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "filter": {
> "inMailbox": "1",
> "operator": "AND",
> "conditions": [
> { "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
> ]
> }
> }, "c1"]
> ]
> }
> {code}
> Email/query will ignore the _*inMailbox*_ condition in the request above.
> *DoD*
> Integration tests to show that Email/query only accept an array of
> FilterOperator or FilterCondition in their respective correct structure.
--
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] [Updated] (JAMES-3450) Email/query reject Filter object with both FilterOperator and FilterCondition
[
https://issues.apache.org/jira/browse/JAMES-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lan Khuat updated JAMES-3450:
-
Description:
According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5, a
filter object in Email/query can either be an array of FilterOperator or
FilterCondition.
Currently we are allowing the request to have properties from both types. This
could lead to unexpected result when querying Email. For example:
{code:java}
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"],
"methodCalls": [[
"Email/query", {
"accountId":
"29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
"filter": {
"inMailbox": "1",
"operator": "AND",
"conditions": [
{ "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
]
}
}, "c1"]
]
}
{code}
Email/query will ignore the `inMailbox` condition in the request above.
*DoD*
Integration tests to show that Email/query only accept an array of
FilterOperator or FilterCondition in their respective correct structure.
> Email/query reject Filter object with both FilterOperator and FilterCondition
> -
>
> Key: JAMES-3450
> URL: https://issues.apache.org/jira/browse/JAMES-3450
> Project: James Server
> Issue Type: Sub-task
>Reporter: Lan Khuat
>Priority: Major
>
> According to JMAP spec: [https://jmap.io/spec-core.html#changes] section 5.5,
> a filter object in Email/query can either be an array of FilterOperator or
> FilterCondition.
> Currently we are allowing the request to have properties from both types.
> This could lead to unexpected result when querying Email. For example:
>
> {code:java}
> {
> "using": [
> "urn:ietf:params:jmap:core",
> "urn:ietf:params:jmap:mail"],
> "methodCalls": [[
> "Email/query", {
> "accountId":
> "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
> "filter": {
> "inMailbox": "1",
> "operator": "AND",
> "conditions": [
> { "hasKeyword": "custom" }, { "hasKeyword": "another_custom" }
> ]
> }
> }, "c1"]
> ]
> }
> {code}
> Email/query will ignore the `inMailbox` condition in the request above.
>
> *DoD*
> Integration tests to show that Email/query only accept an array of
> FilterOperator or FilterCondition in their respective correct structure.
--
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-3450) Email/query reject Filter object with both FilterOperator and FilterCondition
Lan Khuat created JAMES-3450: Summary: Email/query reject Filter object with both FilterOperator and FilterCondition Key: JAMES-3450 URL: https://issues.apache.org/jira/browse/JAMES-3450 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat -- 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-3443) Cannot fetch text/html value when using fetchHTMLBodyValues
Lan Khuat created JAMES-3443: Summary: Cannot fetch text/html value when using fetchHTMLBodyValues Key: JAMES-3443 URL: https://issues.apache.org/jira/browse/JAMES-3443 Project: James Server Issue Type: Bug Reporter: Lan Khuat In an email body *multipart/alternative* part can contains non-textual parts in which *text/** parts can be nested. For Example: multipart/alternative -> multipart/related -> text/html + attachment When retrieving *text/html* or *text/plain* body, instead of filtering only the subParts of the first *multipart/alternative* part, we need to fetch all the nested *text/** part inside 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-3486) Adapt MailboxChangesMethodContract for stability against distributed environment
Lan Khuat created JAMES-3486: Summary: Adapt MailboxChangesMethodContract for stability against distributed environment Key: JAMES-3486 URL: https://issues.apache.org/jira/browse/JAMES-3486 Project: James Server Issue Type: Sub-task Reporter: Lan Khuat h3. Objective Because changes in distributed environment do not happen instantaneously, we need to adapt the contract so that the tests behave in a more reliable way. h3. How Before, we were storing a state manually as a reference point, then the change(s) that we interested in would be conducted after that. This will not work in distributed environment, since the reference state might be stored even before the provisioning process complete and leads to unpredictable result. * We will wait for a new state to be recorded successfully each time there is a change happen * Fetch them sequentially until all the preparation steps are completed * Mark the latest stage * Conduct the change that we are interested in * fetch the result with the latest state as reference point. h3. DoD Integration tests for MailboxChangesMethod should run reliably in distributed environment. -- 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-3521) Fix unstable integration tests in distributed server
Lan Khuat created JAMES-3521: Summary: Fix unstable integration tests in distributed server Key: JAMES-3521 URL: https://issues.apache.org/jira/browse/JAMES-3521 Project: James Server Issue Type: Bug Reporter: Lan Khuat Some integration tests running upon distributed server are failing. There are 3 type of errors: * using fixed String in assertion. * generating ID using the default factory. * State storing is asynchronous. For the State error, we should wait for the State to be saved successfully or ignore when it is not possible to do the former action. *DoD:* all failing tests passing. -- 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] [Updated] (JAMES-3521) Fix unstable integration tests in distributed server
[ https://issues.apache.org/jira/browse/JAMES-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat updated JAMES-3521: - Description: Some integration tests running upon distributed server are failing. There are 2 type of errors: * using fixed String in assertion. * State storing is asynchronous. For the State error, we should wait for the State to be saved successfully or ignore when it is not possible to do the former action. *DoD:* all failing tests passing. was: Some integration tests running upon distributed server are failing. There are 3 type of errors: * using fixed String in assertion. * generating ID using the default factory. * State storing is asynchronous. For the State error, we should wait for the State to be saved successfully or ignore when it is not possible to do the former action. *DoD:* all failing tests passing. > Fix unstable integration tests in distributed server > > > Key: JAMES-3521 > URL: https://issues.apache.org/jira/browse/JAMES-3521 > Project: James Server > Issue Type: Bug >Reporter: Lan Khuat >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Some integration tests running upon distributed server are failing. There are > 2 type of errors: > * using fixed String in assertion. > * State storing is asynchronous. > For the State error, we should wait for the State to be saved successfully or > ignore when it is not possible to do the former action. > *DoD:* all failing tests passing. -- 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-3518) Add method for copying file while running Docker container
Lan Khuat created JAMES-3518: Summary: Add method for copying file while running Docker container Key: JAMES-3518 URL: https://issues.apache.org/jira/browse/JAMES-3518 Project: James Server Issue Type: Improvement Reporter: Lan Khuat h2. Context In James we are currently using *_test-containers_* library with Docker for testing and sometimes, we want to override the configuration of the service inside Docker by overwriting one or more files with our custom files. James is currently lacking this option. h2. How Add a new method in DockerContainer class leveraging already existed method (from _*test-containers*_) for copying file into container. -- 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] [Closed] (JAMES-3518) Add method for copying file while running Docker container
[ https://issues.apache.org/jira/browse/JAMES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lan Khuat closed JAMES-3518. Resolution: Fixed > Add method for copying file while running Docker container > -- > > Key: JAMES-3518 > URL: https://issues.apache.org/jira/browse/JAMES-3518 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > h2. Context > In James we are currently using *_test-containers_* library with Docker for > testing and sometimes, we want to override the configuration of the service > inside Docker by overwriting one or more files with our custom files. James > is currently lacking this option. > h2. How > Add a new method in DockerContainer class leveraging already existed method > (from _*test-containers*_) for copying file into container. > -- 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-3518) Add method for copying file while running Docker container
[ https://issues.apache.org/jira/browse/JAMES-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303142#comment-17303142 ] Lan Khuat commented on JAMES-3518: -- After discussion, this change is deemed not useful to James in anyway and should not be carried out. > Add method for copying file while running Docker container > -- > > Key: JAMES-3518 > URL: https://issues.apache.org/jira/browse/JAMES-3518 > Project: James Server > Issue Type: Improvement >Reporter: Lan Khuat >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > h2. Context > In James we are currently using *_test-containers_* library with Docker for > testing and sometimes, we want to override the configuration of the service > inside Docker by overwriting one or more files with our custom files. James > is currently lacking this option. > h2. How > Add a new method in DockerContainer class leveraging already existed method > (from _*test-containers*_) for copying file into container. > -- 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-3519) User should be able to customize ElasticSearchConfiguration
Lan Khuat created JAMES-3519: Summary: User should be able to customize ElasticSearchConfiguration Key: JAMES-3519 URL: https://issues.apache.org/jira/browse/JAMES-3519 Project: James Server Issue Type: Improvement Reporter: Lan Khuat Builders related to ElasticSearchConfiguration are using _*default*_ access modifier, preventing users from creating their own configuration in their product. *DoD:* All the builders should have _*public*_ access modifier. -- 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
