[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87294

fw-bot · 2022-03-25T15:10:33Z

Purpose

As it has been done for Gmail, we want to add the OAuth authentication
for the incoming / outgoing mail server.

Specifications

The user has to create a project on Outlook and fill the credentials
in Odoo. Once it's done, he can create an incoming / outgoing mail
server.

For the authentication flow is a bit different from Gmail. For Outlook
the user is redirected to Outlook where he'll accept the permission.
Once it's done, he's redirected again to the mail server form view and
the tokens are automatically added on the mail server.

Technical

There are 3 tokens used for the OAuth authentication.

The authentication code. This one is only used to get the refresh
token and the first access token. It's the code returned by the user
browser during the authentication flow.
The refresh token. This one will never change once the user is
authenticated. This token is used to get new access token once they
are expired.
The access token. Those tokens have an expiration date (1 hour) and
are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP
connection.

During the authentication process, we can also give a state that will
be returned by the user browser. This state contains

The model and the ID of the mail server (as the same mixin manage
both incoming and outgoing mail server)
A CSRF token which sign those values and is verified once the browser
redirect the user to the Odoo database. This is useful so a malicious
user can not send a link to an admin to disconnect the mail server.

Task-2751996

Forward-Port-Of: #87261
Forward-Port-Of: #87040

robodoo · 2022-03-25T15:11:23Z

fw-bot · 2022-03-25T15:11:24Z

This PR targets 13.0 and is part of the forward-port chain. Further PRs will be created up to master.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

fw-bot · 2022-03-25T15:14:18Z

Ping @std-odoo, @tde-banana-odoo

ci/runbot failed on this forward-port PR

fw-bot · 2022-03-25T15:29:20Z

This PR was modified / updated and has become a normal PR. It should be merged the normal way (via @robodoo)

std-odoo · 2022-03-25T15:32:10Z

@tde-banana-odoo We continue our adventure

I fixed a test (assertRaise =>ValidationError VS UserError)
I updated .tx/config
I exported the translation for both modules

Let me know if something else is necessary

tde-banana-odoo · 2022-03-25T16:20:34Z

According to your todolist everything is ok 13.0: export .tx/config ^^

tde-banana-odoo · 2022-03-25T16:21:09Z

Upgrade seems in the choux note.

std-odoo · 2022-03-28T06:37:53Z

@tde-banana-odoo Shouldn't we add an exception ? (there's also a master branch for upgrade to add the new module)

tde-banana-odoo · 2022-03-28T08:10:00Z

@std-odoo Seems upgrade is cassé en fait, according to @d-fence

std-odoo · 2022-03-28T08:46:28Z

@tde-banana-odoo So we just need to wait ? (Note that my upgrade branch is green now)

mart-e · 2022-03-28T08:50:24Z

@robodoo override=ci/security
Reason: same as #87040 (review)

tde-banana-odoo · 2022-03-28T08:54:28Z

@robodoo r+ rebase-merge

robodoo · 2022-03-28T08:54:37Z

@tde-banana-odoo, you may want to rebuild or fix this PR as it has failed CI.

robodoo · 2022-03-28T08:54:37Z

Merge method set to rebase and merge, using the PR as merge commit message

tde-banana-odoo · 2022-03-28T08:54:53Z

@std-odoo I launched a rebuild of the template CI .

tde-banana-odoo · 2022-03-29T05:58:21Z

@std-odoo maybe rebase / push to relaunch ?

Bug === When we copy a GMail outgoing / incoming mail server, an error occurs because we try to refetch the access token, based on the same authorization code (which can be used only once). To fix this issue, we do not copy the authorization code (and other related fields). Task-2751996 X-original-commit: 2879976

When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes odoo#81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com>

std-odoo · 2022-03-29T06:32:37Z

@tde-banana-odoo Done :)

I saw the issue about fstring, it should be good for 13.0 (python 3.6 is required)

tde-banana-odoo · 2022-03-29T09:08:17Z

@d-fence Still redish ... anything we did wrong ?

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b

tde-banana-odoo · 2022-03-29T11:46:55Z

@robodoo r+ rebase-merge

robodoo · 2022-03-29T11:47:13Z

Merge method set to rebase and merge, using the PR as merge commit message

Bug === When we copy a GMail outgoing / incoming mail server, an error occurs because we try to refetch the access token, based on the same authorization code (which can be used only once). To fix this issue, we do not copy the authorization code (and other related fields). Task-2751996 X-original-commit: 2879976 Part-of: #87294

When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes #81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b Part-of: #87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 closes #87294 Forward-port-of: #87261 Forward-port-of: #87040 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

robodoo · 2022-03-29T15:21:01Z

Staging failed: timed out (>120 minutes)

mart-e · 2022-03-29T15:30:25Z

robodoo retry

Bug === When we copy a GMail outgoing / incoming mail server, an error occurs because we try to refetch the access token, based on the same authorization code (which can be used only once). To fix this issue, we do not copy the authorization code (and other related fields). Task-2751996 X-original-commit: 2879976 Part-of: #87294

When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes #81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: #87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b Part-of: #87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 closes #87294 Forward-port-of: #87261 Forward-port-of: #87040 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 closes #87498 Forward-port-of: #87294 Forward-port-of: #87040 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b Part-of: odoo#87294 (cherry picked from commit ac62b7d)

Bug === When we copy a GMail outgoing / incoming mail server, an error occurs because we try to refetch the access token, based on the same authorization code (which can be used only once). To fix this issue, we do not copy the authorization code (and other related fields). Task-2751996 X-original-commit: 2879976 Part-of: odoo#87294

When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes odoo#81807 X-original-commit: 3c390c4 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo#87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b Part-of: odoo#87294

Bug === When we copy a GMail outgoing / incoming mail server, an error occurs because we try to refetch the access token, based on the same authorization code (which can be used only once). To fix this issue, we do not copy the authorization code (and other related fields). Task-2751996 X-original-commit: 2879976160bc0777cde1368ed2b69ce821c85ff1 Part-of: odoo/odoo#87294

When the system broadcasts an email response to document followers, if the config parameters `mail.force.smtp.from` or `mail.dynamic.smtp.from` are defined, it will rewrite the `From` address to avoid spoofing the sender's domain. **NOTE**: As of 15.0, this is based on the `from_filter` setting on the corresponding ir.mail_server, rather than the abovementioned config parameters, but the rest of the discussion stands. For example, if the `mail.catchall.domain` is set to `example.com` and an email response comes from: "John D" <john@doe.com> it will rewrite it to: "John D (john@doe.com)" <notifications@example.com> This will make sure the system never sends outgoing email for an external domain, as it has no authority for doing so, and that could break mail filtering/authentication rules (SPF, DMARC, etc.) During this "encapsulation rewrite step", both the original Sender name and their email are preserved, and put into the quoted "name" field of the rewritten address. It seems sensible to preserve as much information as possible about the original sender. Unfortunately, the inclusion of the Sender email in the final name makes it appear to some inbox providers as if the message is trying to deceptively impersonate another person (as many phishing schemes would). As of November 2021 GMail at least does this, and will hide the name in the UI when it happens. It will keep only the rewritten email, which is not very useful in the case of a notification (even though it's more technically correct, of course). This patch removes the original email from the rewritten notification, keeping only the name, considering that the email is not the most important part, and it's better to have one of the two than none. So after the patch, the rewritten address is now: "John D" <notifications@example.com> When there is no name in the original address, we keep only the local part of the email, to avoid the same display issue. The recipient will have to identify the sender based on the context / past messages. closes odoo/odoo#81807 X-original-commit: 3c390c4810136a0fb8b54ba0456ad2a75d2450c1 Signed-off-by: Olivier Dony <odo@odoo.com> Part-of: odoo/odoo#87294

Purpose ======= As it has been done for Gmail, we want to add the OAuth authentication for the incoming / outgoing mail server. Specifications ============== The user has to create a project on Outlook and fill the credentials in Odoo. Once it's done, he can create an incoming / outgoing mail server. For the authentication flow is a bit different from Gmail. For Outlook the user is redirected to Outlook where he'll accept the permission. Once it's done, he's redirected again to the mail server form view and the tokens are automatically added on the mail server. Technical ========= There are 3 tokens used for the OAuth authentication. 1. The authentication code. This one is only used to get the refresh token and the first access token. It's the code returned by the user browser during the authentication flow. 2. The refresh token. This one will never change once the user is authenticated. This token is used to get new access token once they are expired. 3. The access token. Those tokens have an expiration date (1 hour) and are used in the XOAUTH2 protocol to authenticate the IMAP / SMTP connection. During the authentication process, we can also give a state that will be returned by the user browser. This state contains 1. The model and the ID of the mail server (as the same mixin manage both incoming and outgoing mail server) 2. A CSRF token which sign those values and is verified once the browser redirect the user to the Odoo database. This is useful so a malicious user can not send a link to an admin to disconnect the mail server. Task-2751996 X-original-commit: e54d63b3c0f39fd8a05e430442cf84d1d6c8de78 Part-of: odoo/odoo#87294

robodoo added the forwardport This PR was created by @fw-bot label Mar 25, 2022

std-odoo force-pushed the 13.0-12.0-microsoft-outlook-2022-std-ZTzr-fw branch from a81f11f to d058d5e Compare March 25, 2022 15:28

C3POdoo requested a review from a team March 25, 2022 15:30

C3POdoo added the RD research & development, internal work label Mar 25, 2022

fw-bot mentioned this pull request Mar 29, 2022

[ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87040

Closed

std-odoo and others added 2 commits March 29, 2022 08:07

std-odoo force-pushed the 13.0-12.0-microsoft-outlook-2022-std-ZTzr-fw branch from d058d5e to adea7d8 Compare March 29, 2022 06:08

std-odoo force-pushed the 13.0-12.0-microsoft-outlook-2022-std-ZTzr-fw branch from adea7d8 to 6144aa6 Compare March 29, 2022 10:21

std-odoo force-pushed the 13.0-12.0-microsoft-outlook-2022-std-ZTzr-fw branch from 6144aa6 to e5cb742 Compare March 29, 2022 10:23

robodoo closed this Mar 29, 2022

robodoo temporarily deployed to merge March 29, 2022 16:54 Inactive

fw-bot mentioned this pull request Mar 29, 2022

[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87498

Closed

fw-bot deleted the 13.0-12.0-microsoft-outlook-2022-std-ZTzr-fw branch April 12, 2022 17:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87294

[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87294

fw-bot commented Mar 25, 2022

robodoo commented Mar 25, 2022 •

edited

fw-bot commented Mar 25, 2022

fw-bot commented Mar 25, 2022

fw-bot commented Mar 25, 2022

std-odoo commented Mar 25, 2022

tde-banana-odoo commented Mar 25, 2022

tde-banana-odoo commented Mar 25, 2022

std-odoo commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

std-odoo commented Mar 28, 2022

mart-e commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

robodoo commented Mar 28, 2022

robodoo commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

tde-banana-odoo commented Mar 29, 2022

std-odoo commented Mar 29, 2022

tde-banana-odoo commented Mar 29, 2022

tde-banana-odoo commented Mar 29, 2022

robodoo commented Mar 29, 2022

robodoo commented Mar 29, 2022

mart-e commented Mar 29, 2022

[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87294

[FW][ADD] fetchmail_outlook, microsoft_outlook: add OAuth authentication #87294

Conversation

fw-bot commented Mar 25, 2022

Purpose

Specifications

Technical

robodoo commented Mar 25, 2022 • edited

fw-bot commented Mar 25, 2022

fw-bot commented Mar 25, 2022

fw-bot commented Mar 25, 2022

std-odoo commented Mar 25, 2022

tde-banana-odoo commented Mar 25, 2022

tde-banana-odoo commented Mar 25, 2022

std-odoo commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

std-odoo commented Mar 28, 2022

mart-e commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

robodoo commented Mar 28, 2022

robodoo commented Mar 28, 2022

tde-banana-odoo commented Mar 28, 2022

tde-banana-odoo commented Mar 29, 2022

std-odoo commented Mar 29, 2022

tde-banana-odoo commented Mar 29, 2022

tde-banana-odoo commented Mar 29, 2022

robodoo commented Mar 29, 2022

robodoo commented Mar 29, 2022

mart-e commented Mar 29, 2022

robodoo commented Mar 25, 2022 •

edited