Closed DennisSkov closed 1 year ago
Hi @DennisSkov
that's eventually a bug of our module, X-SE-ACCEPT-REGISTRATION-TAC
isn't supported for ModifyDomain.
I wonder why it is joining the contact update with value 0 ... Could also be a matter of wrong additional fields configuration.
That would then also fit to "X-NICSE-IDNUMBER is not set despite it being set on the domain details in the client area.".
Please check if you have the .SE TLD configured via /resources/domains/additionalfields.php
. If not, then all good.
I'll check this case - not sure if I come to it today. I had been sick for 2 days and voilà a lot of support cases waiting.
You can manually execute the command via API and mark the case as Solved in Utilities > Module Queue.
Just don't include the parameter X-SE-ACCEPT-REGISTRATION-TAC
in the update command and setting X-NICSE-IDNUMBER as necessary.
Hope that helps!
Hi @DennisSkov,
17.2.4 is removing X-SE-ACCEPT-REGISTRATION-TAC
for material ownerchange. Do you mind retrying this case?
Another thing: How is the client meant to change the value of X-NICSE-IDNUMBER and X-NICSE-VATID? I don't see a way for the client to do this through the client area.
We inject additional domain fields into the Contact Information Page (Client Area and Admin Area) at the bottom of the page.
Isn't that present? If not, please follow-up.
Hi!
Do you mind retrying this case?
I would but the client needed the change map ASAP for legal reasons so we had to update the details from the Hexonet Control Panel. I trust that it's fixed now ;-) I don't see any of the two fields on the Contact Information page. I've checked with the default templates as well but I see nothing. How would I debug what the issue could be?
six and twenty-one should be compatible with the approach. Check if there's a related javascript error shown in browser console on that page. Have an eye on table tblerrorlog for related PHP errors.
Client-Area: The injection is happening in hook "ClientAreaHeadOutput" in case URL Parameter "action" exists and is "domaincontacts". So, of initial interest would be the URL of the domain contact information page's form. Maybe that one differs somehow... We could eventually change it to match for the HTML Element ID instead.
You may play with returning the below in that hook for that case:
return <<<HTML
<script type="text/javascript">
$(document).ready(function(){
const form = $('form[action="/clientarea.php?action=domaincontacts"]');
console.log("This is the form we identified: ");
console.dir(form);
});
</script>
HTML;
Would that also match if our WHMCS is installed in a sub directory called "client"? The url is /client/clientarea.php?action=domaincontacts
I get a length of 0 if I'm using the script provided. If I change it to $('form[action="/client/clientarea.php?action=domaincontacts"]')
, I get a length of 1.
That's probably the root cause then. Will dive into this then tomorrow. Thanks for all that feedback.
Good Morning!
v17.2.5 is patching the above selector issue.
Cheers!
Hey, @KaiSchwarz-cnic
Sorry for opening this again. We're having the same issue - the additional fields aren't included on the Contact Details page in WHMCS any more. It was working at some point.
It is still working, you just missed reading the Release Notes of the new major versions. :-)
Recommended read: v19.0.0 v20.0.0 v21.0.0
or here:
We reviewed things in direction of template based solutions. Plenty of Template Files to align, but this is beneficial for our resellers and for us as well - it avoids customer support later on.
Hope that helps!
When updating the contact details, we're faced with the following error: Updating Contact Information failed (503 Invalid Parameter: X-SE-ACCEPT-REGISTRATION-TAC).
I can see that the following is added at the end of the module call:
X-NICSE-IDNUMBER is not set despite it being set on the domain details in the client area. Another thing: How is the client meant to change the value of X-NICSE-IDNUMBER and X-NICSE-VATID? I don't see a way for the client to do this through the client area.