## New `calendar.calendar` and 'calendar.calendar.user' models

Before this commit, the user model had a direct One2Many relation with events.
To organize the events into different calendars, new models were introduced,
resulting in the following structure:

- user --o2m--> calendar.user --m2o--> calendar --o2m--> event

Because Google and Outlook support sharing calendars between users, we
introduced a calendar.calendar.user 'membership' model to allow more users
to share one calendar. The model holds the user's access role to a calendar
along with any relevant metadata for each calendar/user pair, such as saved
filters and if it is the user's primary calendar

The calendar_default_privacy field was moved from user_settings to the
individual calendars.

Each user should have exactly one primary calendar, which cannot be deleted.
This is enforced by a migration script and a post_init hook which creates this
calendar for each existing user. For new users, this is handled in a 'Create'
override. A db constraint was added to ensure each user has no more than one
primary calendar.

The is_readonly flag cannot currently be set anywhere within the calendar
module. It is there because some calendars synchronized from Google/Outlook are
readonly (such as public holidays) - Should it stay in the calendar module?

## calendar view

The filter section can be used to edit/create new calendars via buttons
shown on hover. Alternatively, a simple form/list view was added to the
configuration menu.

The colors of the events are based on:
1. Calendars if they belong to the user's calendar
2. partner_id otherwise (just like before)

# Sync

The calendar.model is extended with sync logic, sharing the base sync class with
events. Each calendar also holds its individual sync token so that we only
update when there is new data from google.

Unlike for events, the calendar endpoints do not return an 'updated' timestamp,
meaning we can't rely on last write date to determine which update wins in case
of a conflict - we have to decide which side is authoritative.
In this case -> Odoo

## Sync Flow

1. Synchronize all calendars

Before starting the usual sync flow in 'res.users', we first make a call to
`/calendarList` to fetch all the users calendars. A sync token for this call is
stored in the user settings, similar to the 'global' sync token before. All
calendars which do not have a google_sync_id set, are then posted to Google.

After this part of the request is done, we manually commit the changes. This is
because the google api methods are decorated with @after_commit so that we
don't send data if the sync process fails for some reason. We need all the
calendars to be synchronized when we sync events, thet's why we call
`env.cr.commit()`

Small technical limitation:
Besides the events themselves, we currently only sync the name (summary) field
with google. When this is changed on google however, it does not invalidate the
sync token, meaning we are not notified of this change (changing some other
field on google, such as calendar color, correctly invalidates the sync token)

2. Synchronize the events

Google handles moving events between two calendars -> It returns a canceled
record for the original calendar, and a new one for the moved one. This means we
have to split the process into several parts instead of running the current
flow for each calendar:

2.1: Get events for all calendars from Google

Paths always used to be `.../primary/...` -> now `.../{calendar_id}/...`.
Otherwise the same as before.

2.2 Google -> Odoo

First, determine which should be active after the sync is done.
This is done to prevent canceling events which were moved in Google - E.g.:
- event1 was moved from cal1 to cal2
- when we iterate over the calendars, cal1 tells us the event was canceled
- if the event with the same id is still active somewhere, it means it was moved
 and not canceled, se we leave it be
- cal2 then tells us the new calendar so we can update the event

2.3 Odoo -> Google

This part is mostly unchanged from the previous flow, with calendar ids added to
the api route paths just like before

Task-5485938

Overview
This module integrates the WSMTXCA (Web Service de Autorización de Comprobantes Electrónicos para Mercado de Títulos Valores y Cambios de Argentina) with Odoo's existing Argentinean Electronic Invoicing capabilities. It enables businesses operating in specific markets (like securities and currency exchange, which typically use this webservice) to seamlessly send electronic invoices and other fiscal documents to AFIP (Administración Federal de Ingresos Públicos) using the WSMTXCA web service. This ensures compliance with Argentine tax regulations for transactions falling under this specific regime.

Goal of this Module
The primary goal of this module is to automate and streamline the electronic invoicing process for entities required to use AFIP's WSMTXCA web service. It extends Odoo's standard localization to support this specific AFIP endpoint, allowing businesses to manage their sales and invoicing workflows within Odoo while fulfilling their fiscal obligations accurately and efficiently. This module aims to reduce manual intervention, minimize errors, and ensure that all electronic documents are correctly authorized by AFIP.

Key Features
✅ AFIP WSMTXCA Integration – Connect directly to AFIP’s WSMTXCA web service for electronic invoicing and other fiscal documents relevant to this service.
✅ Automated Document Submission – Send electronic invoices (Facturas Electrónicas) and other supported document types to AFIP in real time.
✅ Compliance with Argentine Regulations – Ensures documents meet all legal requirements for electronic billing under the WSMTXCA scope.
✅ Error Handling & Validation – Validates documents before submission and provides clear error messages from AFIP for quick resolution.
✅ Seamless Odoo Integration – Works natively with Odoo’s accounting and invoicing modules, extending the capabilities of the standard Argentinean localization.
✅ CAE (Código de Autorización Electrónica) Management – Automatically retrieves and stores CAE codes and expiration dates for approved documents.

Functional Flow
The module integrates into the standard Odoo invoicing workflow with specific considerations for WSMTXCA:

Invoice Creation: The user creates a customer invoice in Odoo as usual, selecting a journal specifically configured to use the WSMTXCA AFIP web service.
Data Preparation: Before validation, the module gathers all necessary information required by WSMTXCA, including transaction details, currency, tax information, and specific codes relevant to the market (e.g., securities, exchange operations).
Validation and Submission: Upon validating the invoice in Odoo, the module:
Performs initial data validation.
Constructs the XML request according to AFIP's WSMTXCA specifications.
Establishes a secure connection with the WSMTXCA web service using the configured credentials (Certificate and Private Key for WSAA).
Sends the electronic document data to AFIP for authorization.
AFIP Response Processing:
Approval: If AFIP approves the document, the WSMTXCA service returns a CAE (Código de Autorización Electrónica) and its expiration date. The module automatically records this CAE and related information on the Odoo invoice. The invoice is then considered fiscally valid.
Rejection/Observations: If AFIP rejects the document or returns observations, the web service provides error codes and messages. The module displays these messages to the user within Odoo, allowing them to correct the invoice and resubmit it.
PDF Report: The authorized invoice, including the CAE number and barcode, can then be printed or sent to the customer.
Consultation: The module also allows for querying the status of previously submitted documents or fetching the last authorized document number for a given Point of Sale (POS) and document type via WSMTXCA.
Configuration
To use this module, the following configuration steps are generally required:

AFIP Credentials:
Obtain a Digital Certificate (Certificado Digital) and Private Key (Clave Privada) from AFIP for the WSMTXCA web service. This involves creating a Certificate Signing Request (CSR), authorizing it in the AFIP portal, and downloading the definitive certificate.
Ensure the CUIT associated with the certificate is authorized to operate with the WSMTXCA service via the "Administrador de Relaciones de Clave Fiscal" on the AFIP website.
Odoo Company Configuration:
In Odoo, navigate to Accounting > Configuration > Settings (or general company settings).
Upload the AFIP Digital Certificate and Private Key.
Set the environment (Testing/Homologación or Production).
Journal Configuration:
Navigate to Accounting > Configuration > Journals.
For each journal that will issue electronic documents via WSMTXCA:
Set the "AFIP POS System" (or equivalent field) to "MTXCA" (or the specific identifier used by the module).
Configure the AFIP Point of Sale (POS) number.
Associate the correct AFIP document types (e.g., specific invoice types for securities markets) allowed for this journal and POS.
Testing:
It is crucial to perform thorough testing in AFIP's "Homologación" (testing) environment before moving to "Producción" (production). This involves sending test invoices and verifying their authorization.
The module should provide a mechanism to switch between AFIP's testing and production web service URLs.
Legal Support & AFIP Documentation
The WSMTXCA web service is regulated by AFIP. For detailed legal information, technical specifications, and official manuals, refer to the AFIP website. Key documents typically include:

Manuales de Usuario y Especificaciones Técnicas de WSMTXCA: AFIP usually provides detailed PDF documents outlining the functionality, data structures, error codes, and communication protocols for each web service. These can typically be found in the "Webservices" section of the AFIP site ([www.afip.gob.ar](http://www.afip.gob.ar/)).
Search specifically for "WSMTXCA Manual para el Desarrollador" or similar titles on the AFIP portal.
Resoluciones Generales (RG) de AFIP: Specific resolutions establish the obligation, scope, and conditions for using electronic invoicing and particular web services like WSMTXCA for certain taxpayer categories or activities.
For example, RG AFIP N° 2557/09 and RG AFIP Nº 2758/10 laid groundwork for electronic invoicing in securities markets, though newer RGs might supersede or complement these.
WSAA (Web Service de Autenticación y Autorización): WSMTXCA, like other AFIP web services, requires authentication through WSAA. Documentation for WSAA is also essential.
Disclaimer: AFIP regulations and documentation are subject to change. Always refer to the official AFIP website for the latest and most accurate information.

Why Use This Module?
This module simplifies the process of electronic invoicing in Argentina for businesses under the WSMTXCA scope, reducing manual work and ensuring compliance with AFIP’s latest standards. By leveraging the WSMTXCA web service, businesses can:

✔ Avoid penalties by submitting documents correctly.
✔ Speed up billing processes with automated submissions.
✔ Improve accuracy with built-in validation checks and direct AFIP feedback.
✔ Maintain a centralized record of all fiscal documents within Odoo.

Compatibility
Odoo v16
Requires the base Argentinean Electronic Invoicing module (or relevant Odoo's core localization features for Argentina).

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr