Closed chibenwa closed 4 months ago
I don't really get something...
If we send a reply of the attendance by patching the ics by mail, how is that gonna update the event on the calendar's organizer if it's from a mail he receives in his tmail inbox for example?
If it's just a notification back to the sender that you will attend or not the event, without an update on the calendar... I hardly see the point here?
I'm not convinced your lambda lawyer user will be happy with that for example^^'
Not sure I get all the context.
But I tried a bit of invitations from Google Calendar and Outlook Calendar.
For Google Calendar, TMail frontend still succeeds to extract the yes / no / maybe
button. Clicking those would send a mail back the the GMail sender about the event reply.
While this is not the case for Outlook Calendar. The invitation from Outlook Calendar has no yes / no / maybe
buttons therefore TMail frontend can not do anything to allow users to tell the Outlook invitator about the event reply.
I guess this extension is more about notifying Outlook invitators about the event reply?
Then likely tmail frontend should only call this extension if it can not extract the yes / no / maybe
buttons. Otherwise for example Google invitators could receive 2 mails about the event reply.
Ok misunderstood.
Take this as context:
yes / no / maybe
I guess this extension is more about notifying Outlook invitators about the event reply?
It seems so yes
Then likely tmail frontend should only call this extension if it can not extract the yes / no / maybe buttons. Otherwise for example Google invitators could receive 2 mails about the event reply.
Hmmm maybe the result of the current workaround in place on TMail at the moment? I guess That could change? Unsure, but good raise from you, might be good to test it as well
So the work could be divided into 5 issues:
Regarding the internationalization, we could first go with dummy template on previous tasks, then do the proper refactoring for introducing proper templates depending on the language. Let's say we have two languages at first: fr
(french) and en
(english). There should be a template from each language for each method (2 x 3 = 6). Default templates would be provided under a default folder. The template folder should be configurable, to allow organizations customizing their own templates.
IMO,
CalendarEvent/parse
, and almost all fields can be extracted from ics => We don't need more task for parsingQ:
I18N will be needed.
We will hard-fixed code for the template message? Or should accept add/update template it via web-admin?
- We already
CalendarEvent/parse
, and almost all fields can be extracted from ics => We don't need more task for parsing
Not about parsing here, more about taking the same ICS and tranforming it into a reply one by just modifying a few fields with the help of the ical4j lib?
- the click yes/no/maybe will be the responsibility of the client (mobile), james server just receives the request with method + ids
Yes, obviously
After receiving the request from a client, James will
- JMAP HTTP response
Yes
- Send notification emails to relevant people
Only to the sender, we drop of the other attendants to keep it simple
- do another internal job (maybe send a message to a special queue?, that I remember we did similar with GCSSara)
Not that I understood of
Q:
I18N will be needed.
We will hard-fixed code for the template message? Or should accept add/update template it via web-admin?
As explained, default hardcoded templates under a default folder. The folder location will be configurable, which would allow entities to overrides default templates with their own
Not about parsing here, more about taking the same ICS and tranforming it into a reply one by just modifying a few fields with the help of the ical4j lib?
I am still a bit confused here, The generated "reply invite.ics" file (when Alice clicks YES) will be done by Thunderbird or James?
TMail, it's tmail feature
Just quickly searched ChatGPT
When Alice clicks YES/NO/MAYBE, the imap client will send the IMAP Command to update flags this email to the Mail server
C: C0001 STORE 42 +FLAGS (\Yes_join_event)
.
If I understand correctly, Tmail needs an IMAP processor, to parse commands, generate reply ICS file + reply email
If I understand correctly, Tmail needs an IMAP processor, to parse commands, generate reply ICS file + reply email
This is more a JMAP and web mail extension. The blue bar originally is only for JMAP and web mail for example.
If I understand correctly, the frontend team can also position flags so that TMail remembers answers it sent.
However this is another topic.
BTW to my knowlege those keywords are yet-to-be registered on the IANA registry: https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml
I think in the future we can improve this feature a bit.
Today I think when the User clicks multiple times (maybe the user missed clicks or the network is laggy so the user clicks multiple times) at the Yes/No/Maybe
button, then TMail server likely would send a bunch of spam replies to the sender.
Solution: Maybe 1 table in the database to store the state of the reply, or frontend side can set the JMAP keyword to remember if the user sent ICS reply for this mail.
@quantranhong1999 future maybe? But I think for now the scope has been reduced to something rather simple. Quoting from the initial description:
User will be prompted with a simple choice yes / no / maybe that will act as "shoot and forget".
I think "shoot and forget" is explicit enough :)
Context
From within Twake mail I want to have some base level interactions with my calendar.
Hopefully we would like the integration to be as "light" as possible...
CalendarEvent/parse
method that enable Twake Mail front to display basic information about the event. No action on the event is planned backend side. REF: https://github.com/linagora/tmail-backend/blob/master/docs/modules/ROOT/pages/tmail-backend/jmap-extensions/calendarEventParsing.adocThis ticket is thus an attempt to formulate an easier approach satisfying our client needs in a pragmatic fashion.
Scope
In order to make this achievable I propose to simplify the scope:
Compared to
b.
let's not make it possible to see from twake mail attandance to a given event.Let's also not target to be warned about my availability for a given event from within twake mail.
User will be prompted with a simple choice
yes / no / maybe
that will act as "shoot and forget".How
Twake mail will provide an extension that would take the original ICS, patch event attendance for the connected user, and sends it back to the sender. (this is the standard way to inter-operate calendars together....)
We could position a custom header on this outgoing ICS traffic allowing us to ingest it via the ICS exention we already have in James into the calendar thus updating the attendance in the calendar too.
Given I have a mail with the following ICS:
When I call
Then the following ICS will be generated:
IE:
Wrap it in an email from connected user to the organizer of the ICS and send it.
The HTML display can be taken from OpenPaaS.
Internationalisation
As this is user facing, I8N will be needed.
We can provide a set of 3 templates per language on the classpath.
The language can then be passed into the JMAP method call:
Similarily we would also implement the
CalendarEvent/reject
andCalendarEvent/tentative
JMAP methods.