Closed hieutbui closed 1 year ago
@chibenwa @Arsnael I have some problems with the Filter/set. Please check it!
Let me have a look...
I can confirm with postman it happens on preprod
What I don't get is that we have integration tests covering the case you mention and they pass... so it's hard to get what's going on
Will study the matter, thanks for the report
Talked too fast... working for memory, not for distributed and we dont play all distributed tests on the CI. So yes there is an issue
not for distributed and we dont play all distributed tests on the CI
BTW should we enable CI to run distributed JMAP tests? at least for TMail? Not the first time we've spotted this and this time leads to a bug.
We could... I spotted the issue though, it's from James and the tests in james don't really cover this case as well. Fix here:
@hieutbui Fix has been merged on James project.
Now I'm working getting that merged on tmail-backend with proper updates. When it's merged on tmail-backend, I will deploy the master branch image containing the fix on preprod so you can test.
Does that sound good to you?
@hieutbui Fix has been merged on James project.
Now I'm working getting that merged on tmail-backend with proper updates. When it's merged on tmail-backend, I will deploy the master branch image containing the fix on preprod so you can test.
Does that sound good to you?
Glad to hear that. It will get my work back on track, please let me know when it's done. Thanks a lot!
Unfortunately a work tierce got merged on james meanwhile that trashes the build on tmail-backend... I pushed a fix but it will make the process longer
I see! A fix will take time to be good. I'll be waiting. Btw, thank you for your update real quick!
@hieutbui Fix deployed on preprod. I tested again with postman and this time I get the correct behavior
By the way the conf might show up alright already, as the filter actions were successfully saved on the backend, it's just we forgot to serialize them when serving the api (showing thus default values)
Let me know if it's fine for you
@Arsnael I tested it and everything works good.
Just 1 question, can we control the order of actions? Cause now user can define which action is selected first. For example, If i send request with "markAsSeen" and "markAsImportant" before "appendIn", can response be the same:
"action": {
"markAsSeen": true,
"markAsImportant": true,
"appendIn": {
"mailboxIds": [
"aa162850-32cf-11eb-995c-a3ae66e9f96a"
]
},
"reject": false,
"withKeywords": ["abc", "def"]
}
@hieutbui No there is no orders of actions atm Is this really necessary though, as they are all not really dependent of others? I mean that you append a mail in a mailbox and mark it as seen and important, in one order or the other, end result is the same logically, right?
@Arsnael Yes, I know that logically they are the same. I just consider if it can be ordered according to user selections.
Not on the backend side, the rendering in the response will be always ordered the same. It would add complexity for not much tbh
Description of the bug
When send a request with multiple actions, the response is wrong:
Reproduction Steps
Expected result
Context
Additional information
https://github.com/linagora/tmail-backend/assets/80142234/cb864603-52b9-4c6b-b91c-567324181372