Docusign API - Views/Recipient with In Person Signing - javascript

I have everything working for the views/sender, and I have envelopeId/recipients working - so I know every piece of data that I think I need.
In my envelope I have 2 inPersonSigners. The first is a "client" always, and the second is an employee, always.
I have the UserId, RecipientGuid, RecipientId, UserName, etc. Since these are In Person AND Embedded signers, they do not have email addresses.
I have been unable to get the recipient view to return the URL because the "UNKNOWN_ENVELOPE_RECIPIENT" OR "INVALID_ENVELOPE_RECIPIENT" errors I am receiving with every combination of data I have tried.
In the documentation it states you only need the clientUserId or a userName and Email combination. I have tried a variety of these, and still cant get the in person, embedded signing recipient view to return the correct response. 100% of the time it is an envelope recipient invalid error. I have tested every combination I can think of in postman and code;
inPersonSigners
[0]
clientUserId:"SomeoneHelpfulsomeonehelpful#stackexchange.com"
hostEmail:"someonehelpful#stackexchange.com"
hostName:"StackExchange User"
note:""
recipientId:"1"
recipientIdGuid:"xxxxxxxx-xxxx-xxxx-b65d-3bb23fbf8860"
requireIdLookup:"false"
roleName:"1"
routingOrder:"1"
signerEmail:""
signerName:"Test Testeroni"
status:"sent"
userId:"xxxxxx-xxxx-xxxx-913e-c347a9f2dafd"
I just need to be able to take the data above, post to /views/recipient and get the response url.
I think the problem is that when this document template is being created, via Drawloop ->Docusign, there is no Email being passed, but there is a Name and clientUserId. Hopefully its something simple that I have missed after looking at the same thing for hours.

The below sample invocation/POST would work. I did notice that your clientUserID resembles an email# - typically this value is in a GUID format. Something to keep in mind.
POST
https://demo.docusign.net/restapi/v2/accounts/459963/envelopes//views/recipient
{
"authenticationMethod":"email",
"username": "StackExchange User",
"email": "someonehelpful#stackexchange.com",
"returnUrl":"http://www.something_you_provide.com",
"clientUserId":"SomeoneHelpfulsomeonehelpful#stackexchange.com"
}

Related

Meteor.js - Fetch/Get Enrollment token (from Accounts.sendEnrollmentEmail)

I can't figure out how to get the enrollment token from the Accounts.sendEnrollmentEmail function.
I know this function sends a direct mail towards the user which in the end looks something like this:
http://localhost:3000/#/enroll-account/FCXzBbqHInZgBlLaOpu8Iv11jP9DJEG-e1auAHDsh6S
However, I would need to somehow get only to the token part FCXzBbqHInZgBlLaOpu8Iv11jP9DJEG-e1auAHDsh6S as I want to send enrollment mail trough a different service (e.g Postmark)
How to do this?
The Accounts.sendEnrollmentEmail(userId, email) function generates a random token and saves it in the user's services.password.reset.token field.
The code that generates the token is:
var token = Random.secret();
var when = new Date();
var tokenRecord = {
token: token,
email: email,
when: when
};
Meteor.users.update(userId, {$set: {
"services.password.reset": tokenRecord
}});
(You can view the function's source code here).
It then sends an email to the user using the Email package. If you want to use a different service to send the email, you basically have 2 options:
Use the same convention yourself (i.e, create the same record and use your own email service in your own function).
Use the existing function, allow the mail delivery to fail silently and then query the user's document for the token and send the email yourself.
Neither is a particularly good option, but both will work for the time being. I wish they had refactored this part into its own function.
Note that the accounts packages are expected to undergo some changes towards the release of the next Meteor versions.
BTW, this function is very similar to Accounts.sendResetPasswordEmail, which you may also wish to override or create your own version.

User-provided fields not returned upon parse-login

I'm using the Parse REST API to login to my app (using the endpoint: https://api.parse.com/1/login). According to the docs, I should, when I login receive all the user-provided fields, in other words, the custom fields for my User-object.
From Parse Docs:
The response body is a JSON object containing all the user-provided
fields except password. It also contains the createdAt, updatedAt, objectId, and sessionToken fields.
But I only receive the following:
{createdAt: "2015-01-28T20:21:23.554Z", objectId: "6Wg0lOKCww", sessionToken: "Mvgr5knHqnTfqlI6KqJBLSxBr", updatedAt: "2015-01-28T20:21:23.554Z", username: "testuser"}
Am I doing something wrong or understanding something wrong? I would rather not have to query the Parse-server for additional data.
Thank you!
Not sure if this was a bug in their system at the time, but it seems to work as intended now. Custom user fields are returned upon login (if they are not null/undefined).

Facebook api, get user liked page using FB.api

Using this method, facebook will return an object of the user's liked pages
FB.api('/me', {fields: 'gender, first_name, last_name, email, likes'}, function(response) {
console.log(response);
}
result
email: "ariel#dropbox.com"
first_name: "Ariel"
gender: "female"
id: "178006027123671"
last_name: "Yeung"
likes: Object data: Array[2]
However, I only want to get the object whether this user is liking my facebook page
As https://developers.facebook.com/docs/graph-api/reference/user/likes describes, you can ask whether the user likes a certain page using
/me/likes/{page_id}
Since you are asking for specific user fields already, you probably don’t want to make a separate API call for that – but you can fit it in there as well, using field expansion:
/me?fields=gender,first_name,last_name,email,likes.target_id({page_id})
If the user likes that particular page, you get a likes property in the response data.
(Not sure if that works using the syntax you are using currently as well, passing the fields via object, but you can simply try: {fields: 'gender, …, likes.target_id({page_id})'} … let us know if that works, thanks.)
Edit: Although this will still work, as long as you get user_likes permission from the user, Facebook will not approve the use of that permission for this singular purpose. Like Gating in any way, shape or form is not allowed any more.
You canot get the list of users liking you page via graph api. So, you can not check wether or not a user has like your page directly.
You already have the likes of a user, just loop through them and check that your page is liked or not.

Generate card_error in stripe.js while testing

I dont know this can be done or not, but i was wondering is there any way to generate card_error on stripe for testing?
To clarify my question here's what I want to do:
Stripe provides varieties of card numbers for testing purposes
(here). Along with this it also provides methods for form
validation(eg. I enter 34/2013 as expiry date and i'll get invalid
date error by validation then and there).
But i want to create a situation where a
user enters an expiry date which is a valid date (say 12/2015) but
its not the real expiry date of the card, so that on sending this
information to stripe, i recieve an error in json form named
card_error. (here)
How can this be done?
There are two approaches you could take to this.
You pass the stripe API call a callback function. This callback is the unit of code that you want to test with the card_error type of response
'test card_error is handled correctly': function() {
var response = {
type: 'card_error',
message: 'The human readable message',
code: 'invalid_cvc'
myStripeCallback(response)
// Make assertions down here about what happened when
// you called the function with the error message
// Maybe it emailed you, maybe it displayed a message
// to the user. I would then probably make another test
// for each `code` that I cared about.
}
The second approach would be to mock out the stripe api call entirely. Check that it was called with the right arguments and then call the provided callback with the error response that you wanted to deal with in that test.
Im sorry, turned out to be stripe already has special codes for this purpose. I over looked that part of the page despite going through the page several times.. stupid me! :-/
Anyways here are the codes:
source: https://stripe.com/docs/testing

Struggling to build a JS/PHP validation function for my app

I have a web service that returns a JSON object when the web service is queried and a match is found, an example of a successful return is below:
{"terms":[{"term":{"termName":"Focus Puller","definition":"A focus puller or 1st assistant camera..."}}]}
If the query does not produce a match it returns:
Errant query: SELECT termName, definition FROM terms WHERE termID = xxx
Now, when I access this through my Win 8 Metro app I parson the JSON notation object using the following code to get a JS object:
var searchTerm = JSON.parse(Result.responseText)
I then have code that processes searchTerm and binds the returned values to the app page control. If I enter in a successful query that finds match in the DB everything works great.
What I can't work out is a way of validating a bad query. I want to test the value that is returned by var searchTerm = JSON.parse(Result.responseText) and continue doing what I'm doing now if it is a successful result, but then handle the result differently on failure. What check should I make to test this? I am happy to implement additional validation either in my app or in the web service, any advice is appreciated.
Thanks!
There are a couple of different ways to approach this.
One approach would be to utilize the HTTP response headers to relay information about the query (i.e. HTTP 200 status for a found record, 404 for a record that is not found, 400 for a bad request, etc.). You could then inspect the response code to determine what you need to do. The pro of this approach is that this would not require any change to the response message format. The con might be that you then have to modify the headers being returned. This is more typical of the approach used with true RESTful services.
Another approach might be to return success/error messaging as part of the structured JSON response. Such that your JSON might look like:
{
"result":"found",
"message":
{
"terms":[{"term":{"termName":"Focus Puller","definition":"A focus puller or 1st assistant camera..."}}]}
}
}
You could obviously change the value of result in the data to return an error and place the error message in message.
The pros here is that you don't have to worry about header modification, and that your returned data would always be parse-able via JSON.parse(). The con is that now you have extra verbosity in your response messaging.

Categories