Layouts were not accepted by Pingen due to the fact that the class that we added to the recipient's address was not present in stable versions.
The format was therefore not adapted to Pingen.
We then remove this class to fix layouts in stable versions.
closesodoo/odoo#29976
Sending a letter resulted systematically in an error due to the insertion of the binary of the PDF in the JSON sent to IAP-services.
closesodoo/odoo#29880
Pingen validates the format of documents before sending them. These are the elements that it checks and how when ensure that the constrains are validated:
- The recipient's address should appear in a predefined area
--> Move the address to this area and reduce the font-size if the address is too long
- The destination country should be the last line of the address
--> Sometimes, the Tax ID was in this zone, so we add a margin after the address
- Above the Address Area, there should be a Postage Area that should be completely empty
--> Make the background white to avoid having a background image in this area
--> Crop the header if it takes too much space
- There are margins of 5mm all around the document
--> Crop the footer 5mm above the bottom of the page if it takes too much space
- There is a square in the bottom left of the document that should be empty
--> Add a margin on the left of the footer
closesodoo/odoo#29522
the fix merged in cb8bd299fc
was only tackling half the problem. When you assign a user to an
activity, the said user will be notified by email. This also occur if
you change the assignee to the next activity even if you change it to
the same user.
This commit ensures that we only write on the user_id field when we
create the next activity and not during the update.
Since commit b6a981405e we require a
certain key in the context to apply the custom snailmail report layout.
This was badly managed and would eventually confilt inside the modal
that links snailmail and the mail composer.
This fix stabilises the biehaviour by properly propagating the context
key.
The previos format displayed the fields 'street' and 'street2' on two different line, making the address too big for the address area allowed by Pingen.
Up until now, when we wanted to post a single document, it's base64 blob
was uploaded to the snailmail server to estimate the cost of the
transaction. We now use the 'batch' apporach that will estimate the
price based on 1 page per document.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
In order to ease the integration with the snailmail posting service provider,
We will generate specific reports with a layout that fits their
criteria.
In short,
* we specify the postition of the recipient's address on the
document
* we force the A4 format
This also support the din5008 type B report.
Martin Trigaux