On the situations where DocuSign envelopes get automatically created through API, what is the best practice over unexpected characters? I have situations where through the night someone's envelope contains texts with <0x0B> and that breaks the DocuSign Connect and causes that DocuSign Status record not getting created in Salesforce just because the unexpected character or a hexadecimal value is in one of the envelope data fields.
What are some references to use in order to know all these unexpected characters and maybe set up a way to block making the API call when one of them is present? OR is there a way to force update the envelope to remove those unexpected character(S)?
Connect Failure Log shows an error like below:
https://na2.docusign.net/Member/SFIntegration.aspx :: Error - '', hexadecimal value 0x0B, is an invalid character. Line 1, position 11539.
Update: Just realized the unexpected character is hidden in the post. Here is the character that causes the failure. Notice the hexadecimal character between the words:
Sounds like the error is in the SFIntegration.aspx code that receives the Connect notification, not in the Connect webhook system itself.
Connect should be able to handle any characters in an envelope. If not, then there is a bug.
Where was this rogue character? In the envelope's email subject line? Somewhere else?
Thank you.
Related
I'm trying to connect to mongoDB with the new password with special char as shown in the screenshot. It gives error as URL malformed due to special character in it.
Initially I was able to connect with normal password.
I tried to add escape characters in password with no luck.
Does anybody have came across this situations or know the solution? Any leads highly appreciated[![enter image description here][1]][1]. Thanks.
Click on the Fill in connection fields individually then input the fields.
It will create the URI with escaped characters for you.
If your password includes special characters you need to encode all special characters. you can find it on this link: https://www.w3schools.com/tags/ref_urlencode.asp
Good afternoon all! I am looking for some guidance to see if this type of validation is possible. I work for a college and am using a form that pushes to our CRM when complete. I am looking for parsley to only validate the email address field IF they enter their college email address. Is this possible? I am trying to weave out personal email accounts and keep everything uniform with the same email address.
Thanks in advance!
You can do that e.g. by using data-parsley-pattern and defining a pattern that matches only the required mail addresses. The pattern to validate against the mail addresses you mentioned in your comment might look like this:
.*#(mail\.)?walshcollege.edu$
This matches everything that:
Starts with any number (*) of arbitrary characters (.)
Followed by an #
Might be followed by "mail.". The dot is escaped to avoid the special meaning "any character", the question mark means "might be there or not" and the parentheses make the question apply to the complete string.
Ends with walscollege.edu (the $ means the end of the string)
If you also want to make sure that an mail address is inserted you need to add data-parsley-required as Parsley by default does not validate empty fields.
Also keep in mind that Parsley validation is only client side, so you should add validations in the server to really make sure that no wrong mail address is used.
Trying to get messages from Gmail using RESTFul API using get operation and some messages are returned empty labels (other parts of the payload are ok).
What is the reason to get empty labels ?
Thanks
Messages without labels are archived messages.
This seems like expected behavior. If they don't have any labels (e.g. not even INBOX) then they are simply in All Mail (e.g. they have been archived and are in the mailbox, etc).
I am trying to send an email using CakePHP 2x utility CakeEmail, I am getting all my values dynamically as below-
$Email = new CakeEmail();
$Email->from($from_id);
$Email->to($to_id);
$Email->subject($subject);
$Email->send($body);
Sometimes email is sending without any failure, but sometimes it wont. Finally I found the issue with the subject line length. Whenever my subject line is getting bigger then the email is not sending properly through programmatically. But, whenever my subject is line is less than nearly 75 characters then its working perfectly. So, how can I fix this issue by enlarging subject line length. Normally in gmail there is no restriction of subject length. But programmatically it is not allowing in CakePHP 2x CakeEmail utility.
Do you use SMTP. If not then please send mail using SMTP. and the check.
Please follow the given link bellow.
http://book.cakephp.org/2.0/en/core-utility-libraries/email.html
Got the solution by myself. Simply change the core behavior of Email functionality in Cake Lib. Open \lib\Cake\Network\Email\MailTransport.php and edit line no - 47 as below
$this->_mail($to, str_replace(array("\r","\n"), "", $email->subject()), $message, $headers, $params);
So, the basic change is to remove "New Line" & "Carriage Return" from Subject text. Whenever our subject text becomes more than 75 characters, framework will automatically put new line in the subject text, which wont work while on sending emails.
We have a user that our corporate portal cannot fetch the groups for from AD.
On the portal logs we see this error:
javax.naming.PartialResultException: Unprocessed Continuation Reference(s) remaining name ''
I've Googled for the error and the best symptoms that seem to describe this case and how to resolve it are here: http://www-01.ibm.com/support/docview.wss?uid=swg21232921
Assuming we don't want to change the configuration just because of one user but to amend the data of this specific user can someone please explain me how can recognize this when examining the user's record in the AD? Is this something to do with his groups assignments and if yes then what should I look for?
I just ran into this.
I got around it by setting your InitialDirContext environment to have the Context.REFERRAL key set to "follow".
According to the Javadocs, that key can be "follow", "ignore", or "throw". The default is determined by the provider you use, which is probably "throw".
Check out this link for a bit more data on what your API is telling you: http://www.jspwiki.org/wiki/ActiveDirectoryIntegration
I'm not an expert on this API but can explain at least what I think is going on based upon that doc & knowledge of what AD is doing. :)
AD returns what are called "referrals" when you do searches that have naming contexts outside of this local server/search but in the logical scope of your request. This is per RFC request. Think of a referral as a hint to you the app that there might be more data out there...ie, that is, the AD server is saying "here are the results I have for you but, you should know, there is someone else that might have more...go here to find out."
Referrals aren't an "error" they are a hint to the app.
It seems that your LDAP API is throwing an exception when encountering them. Per the docs I referenced above, it looks like you can either swallow them or chase the referral to find out if there is more data.
add this for env properties
env.put(Context.REFERRAL,"follow");
Also one of the issues that i found was that the incorrect search query string in ldapContext. The incorrect query formed due to wrong format of parameter throws:
javax.naming.PartialResultException: Unprocessed Continuation Reference(s) remaining name ''
But if we add the parameter Context.REFERRAL="follow", then it does not throw an exception but neither does it return result.
The parameter to ldap query string should also match the that is being accepted by LDAP else it will throw the same error.