- Proxy user is no longer a computed store=True field, but a proper one.
The type cannot be deduced just by some field on the company.
A company may be Italian and also use Peppol, so the two Proxy Users
must be different.
- The Proxy user `get_proxy_identification` method needs a proxy_type
argument, otherwise the method won't know if the current override
is to be applied or not. It cannot be handled by a field of the user
itself because it is also used contextually to the user creation.
- new `_get_default_enable_send_by_post` function on the Send and Print
wizard, so that it can be overridden by the features of the move
- Renamed `_compute_send_mail_extra_fields`
to `_compute_fields_from_moves_state`
Part-of: odoo/odoo#122194
Currently, the migration key is stored through a workaround as a config parameter,
because the behaviour needed to be changed in stable.
Now, several things can be fixed:
- `account_peppol_migration_key` is now a field on `res.company`, not `account_edi_proxy_client.user`
- `account_peppol_attachment_ids` can be removed as the specs changed and it's no longer necessary
- `peppol_proxy_state` can be removed as it's no longer useful after `enable_peppol` was added
- SQL constraints need to be changed to only include active users.
This allows users to deregister/migrate away from Peppol and then re-register later, with their previous edi user being archived
closesodoo/odoo#129595
Related: odoo/upgrade#4980
Signed-off-by: Laurent Smet (las) <las@odoo.com>
`account_peppol_migration_key` is a related field, stored on the `account_edi_proxy_client.user`.
We want to allow users to provide a migration key when they want to register as a new peppol participant,
migrating their existing peppol registration from another smp.
However, before they save and validate their registration,
there is no `account_edi_proxy_client.user` associated with the company and
hence the `migration_key` is never saved and never sent to the IAP server.
The solution in master will be to move this field to `res.company`
but in stable the workaround is to store it in `ir.config_parameter` and make it a computed field,
where the config parameter is updated in the inverse method on `account_peppol_migration_key`.
closesodoo/odoo#129691
X-original-commit: d5edca101e6a1dd751a3c95d713831e99fc18462
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Currently, when a user requests a migration key, we set them as 'canceled' and show the migration key.
That means, they won't receive new invoices/invoice status updates.
However, the idea of the migration is that a user should be reachable at all times
and we should receive documents for them up until they are fully migrated to another service.
The solution is to keep `account_peppol_proxy_state` as `active` when they request a migration and display the migration key.
On the IAP side we will check with a cron whether they have migrated or not.
A migrated user is then archived on the IAP side.
That means that whenever we run a cron on the client side, the edi user would not be found,
so the edi user will be archived in `_make_request`.
We can then safely change the `account_peppol_proxy_state` to `not_registered`.
closesodoo/odoo#129166
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently, users cannot deregister from Peppol.
There is an option to migrate away (i.e. request a migration key) but not every provider supports migration.
It is not straightforward to deregister from Peppol once a participant is marked as "prepared for migration",
so the users really should deregister instead.
Also, it is important to run the cron one last time for the user to fetch new documents/message status updates
they've received since the last time the cron ran.
closesodoo/odoo#128867
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit adds several improvements in Peppol onboarding process:
- Adds a phone number verification process
- Adds a possibility to migrate away/cancel the registration
- Adds a possibility to update contact details for the participant
- UX improvements like autosave
- Set 0208 as the default EAS code for Belgium
- Add a check for certain peppol endpoint numbers (based on Peppol schematron rules)
task-3060814
closesodoo/odoo#127092
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This commit fixes small bugs:
- Sometimes we don't receive the attachments' file name from the proxy. Instead of saving the attachment with `False` as the filename, we should default to something.
- If for some reason the participant's status is changed on the proxy server after documents have been sent, retrieving the message status will traceback. This commit adds a condition to catch this case.
- Currently, the participant status is only updated if their application is pending. But it can happen that they are approved but not registered to the SMP. Participant status should be checked for approved edi users too.
closesodoo/odoo#125437
X-original-commit: a70a388cc6cba1f0f440ca7b9dafe9b6ef6593f4
Signed-off-by: Laurent Smet <las@odoo.com>
This commit adds proxy urls for prod and test peppol servers that are missing at the moment.
Additional small fixes:
- `default_peppol_move_state` when receiving a new document should match the state on the iap server
- not committing when running tests
closesodoo/odoo#122385
X-original-commit: ec895c56c36794f76b5b778833cee655a7c9bfec
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
This commits adds `account_peppol` module that allows:
- Registering as an account edi user and send an application to the peppol proxy,
where the participant can be approved or rejected after reviewing the documents attached.
- Sending invoices by selecting 'Send via Peppol' option in the send & print wizard.
- Receiving peppol documents.
task-3159912
closesodoo/odoo#119120
Signed-off-by: Laurent Smet <las@odoo.com>