[16.0][IMP] sign_oca enable the user to select all the value of type char, text or m2o from the res.partner object

[sergiocorato]

With this PR all fields of type char, text and m2o are pre-filled during sign request, if model used is res.partner.

[OCA-git-bot]

Hi @etobella,
some modules you are maintaining are being modified, check this out!

[mymage]

LGTM, functional test ok

[luisDIXMIT]

Hi @sergiocorato, I tested your code, but I think it isn't necessary to load all partner fields of type char or text if they aren't going to be used. Important fields like name, email, or phone are already pre-filled. @etobella WDYA?

[sergiocorato]

Hi @luisDIXMIT and thanks for the review.
The reason to add all these fields is to create more complex form compiled on the fly, see example below.
This PR add also all the fields added from additional module, like firstname and lastname, which are essentials for many usage.

[pedrobaeza]

Isn't this dictionary thing something outside of the scope of the PR message?

[TheMule71]

Just have a look at https://github.com/OCA/partner-contact
this change allows dynamic integration with those modules.

Eg. partner-firstname virtually makes name a technical field, and input is done via 2 fields (first and last name). Same for partner_middlename.
Other modules just add fields that naturally complement basic personal info, like partner_contact_nationality, partner_contact_birthdate, partner_contact_birthplace and are very common on forms.

It make sense to have those pre-filled.

[sergiocorato]

Isn't this dictionary thing something outside of the scope of the PR message?

Corrected, thanks (the first idea was different).

[etobella]

I don't like this approach as we are getting all the data of the partner....

My suggestion would be to match with the possible field names. WDYT?

[sergiocorato]

A better approach could be to make only visible the fields availables to group base_user? If there were some.
A mere list seems a hard approach, or not?

[etobella]

Yes, but it could be actually a portal user 🤔

The thing is that it is more limited to attach to the fields that we have defined

[sergiocorato]

I added a with_user to ensure only fields accessible to the user opening the form are added.
Do you think this is enough?

[luisDIXMIT]

Hi @sergiocorato, I can see the potential of your functionality. I tested it functionally, and it looks good. Check out Enric's comments and we go ahead with the merge!

[luisDIXMIT]

LGTM!

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[victoralmau]

Reviewing this I remembered one thing that I think could solve all use cases.

The default_value field or other extra field should be able to indicate a regular expression, that way, when creating a sign.request linked for example, to project.task, the value of the fields with regular expression, will be defined according to it {{{object.partner_id.display_name}} for example for the customer value.

What do you think @etobella ?

[kobros-tech]

please, I need to confirm if the custom fields like vat, phone are prefilled.
I am no longer having them prefilled, so I need someone to review and confirm to me if it is a bug or a mistake from my side.

===================================================

Corrected, I have to add in the default the technical name of the field of res.partner, there was an issue when I create the request then I update the default fields the change does not appear on the sign request and I have to create a new request to have the fields prefilled.
I think it is not related to that commit but to the module itself.

[kobros-tech]

welcome to tell your opinion about this one:
#99

[kobros-tech]

please add my changes

[kobros-tech]

This line was suspecious to me, I logged and saw that all user_id are just empty recordset:

res.partner(7,)
res.users()
{'id': 7, 'message_main_attachment_id': False, 'email_normalized': 'mark.brown23@example.com', 'activity_user_id': False, 'activity_type_id': False, 'activity_type_icon': False, 'activity_summary': False, 'activity_exception_icon': False, 'name': 'Marc Demo', 'display_name': 'YourCompany, Marc Demo', 'translated_display_name': 'YourCompany, Marc Demo', 'title': False, 'parent_id': False, 'parent_name': False, 'ref': False, 'tz_offset': '+0300', 'user_id': False, 'vat': '123456789', 'same_vat_partner_id': False, 'same_company_registry_partner_id': False, 'company_registry': False, 'website': False, 'function': False, 'street': '3575 Buena Vista Avenue', 'street2': False, 'zip': '97401', 'city': 'Eugene', 'state_id': 'Córdoba', 'country_id': 'United States', 'country_code': 'US', 'email': 'mark.brown23@example.com', 'email_formatted': '"Marc Demo" mark.brown23@example.com', 'phone': '(441)-695-2334', 'mobile': False, 'industry_id': False, 'company_id': 'YourCompany', 'contact_address': 'YourCompany\n3575 Buena Vista Avenue\n\nEugene COR 97401\nUnited States', 'commercial_partner_id': 'Marc Demo', 'commercial_company_name': 'YourCompany', 'company_name': 'YourCompany', 'barcode': False, 'self': 'Marc Demo', 'create_uid': 'OdooBot', 'write_uid': 'Mitchell Admin', 'im_status': 'offline', 'signup_token': False, 'signup_type': False, 'signup_url': 'http://localhost:8069/web/login?db=sign_survey_16&login=demo', 'additional_info': False, 'phone_sanitized': '(441)-695-2334', 'phone_mobile_search': False, 'current_date': '04/02/2025'}

[kobros-tech]

I suggest to add this line above the for loop:
user_id = self.env['res.users'].search([("partner_id", "=", self.partner_id.id)]) for field_name, field_info in ( self.env["res.partner"] .with_user(user_id) .fields_get() .items() ):
as the field user_id is not the partner user account, but the sales person if present!

In contrast, passing with_user() function did not make change to the returned dictionary, I suggest keeping the former code as it was.

[kobros-tech]

please, don't merge before fixing this line, some models don't have name field and this should be in account as I catch these errors:

File "/opt/odoo/auto/addons/sign_oca/controllers/main.py", line 87, in get_sign_oca_info_access
return signer_sudo.get_info(access_token=access_token)
File "/opt/odoo/auto/addons/survey_sign_oca/models/sign_oca_request.py", line 88, in get_info
vals = super().get_info(access_token)
File "/opt/odoo/auto/addons/sign_oca/models/sign_oca_request.py", line 435, in get_info
{field_name: self.partner_id[field_name].name}
AttributeError: 'serial.shipping.container.code' object has no attribute 'name'

[kobros-tech]

Manage KeyError if user add a wrong technical field name.

            try:
                # name_get method returns a list, if name exists the list looks like:
                # [(123, 'Foo')]
                name_get = self.partner_id[field_name].name_get()
                if name_get and name_get[0]:
                    partner_fields_dict.update(
                        {field_name: name_get[0][1]}
                    )
            except KeyError:
                pass

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.