According to Docusign
Data Population Scope is a great way to speed up the signing process by duplicating their data throughout the document automatically
I want to prevent this replication from happening programmatically.
Is there an argument I can pass to Text that would prevent this? Maybe something like:
Text(data_label="some_unique_label")
I tried doing
Text(name="some_unique_name")
This did not prevent data linking between other Text fields. According to the Docusign documentation I need to set a unique data label for each Field. However, I am not finding a data_label option for Text.
You're looking for the tabLabel parameter.
Data is populated between fields that have the same tabLabel, so if you make those unique, they won't share data.
Related
I am using powerform to display the DocuSign to get the signature from users. There are few custom fields where I was populating data in read only mode in Demo env. Somehow the data in readonly mode stopped appearning since yesterday.
Can anyone help here?
I just tested a Powerform. Read-only fields with default text are shown (read-only) in the signing ceremony for the Powerform.
I agree that read only fields with no default text do not show on the document when it is shown in the signing ceremony. But why should they if they don't have default text?
How were you setting the read-only fields? Were you using the Powerform URL? If so, then signers could very easily change the "read only" values themselves by changing the URL themselves.
If this is the case, then the upgrade may be considered by the product group to be the "closing of a loophole."
If, on the other hand, you had a secure method for setting Powerform field values in a truly read-only pattern, then updates to the Powerform system may have missed this issue as a regression test.
Or were you setting the value of the read only field in the template itself? I just tried that and it worked fine: the field, with its read-only text, is shown in the document.
Please EDIT / UPDATE your question to describe how you are setting the values to be read-only.
Using the Docusign API, I am trying to change the fields that exist on a document. When I first create the document, I am able to change field values using "tabs." I get how to do that.
When I am trying to edit, or in Docusign's terms "correct," a document after it has been sent out, but before being signed, I am having trouble figuring out how to access those fields again to change the values.
I have tried using the API avenue described here ( PUT /v2/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}/fields ), but even after successful calls, the values of the fields aren't changing, and I believe it is because I should be trying to access the tabs, as I did when first changing the tab values as I created the document, instead of targeting the fields, since the two seem to be different. Any thoughts? Thank you in advance for your answers.
To update Tab values you should use the putRecipientTabs api.
Once a signer completes the Signing process, the tab values cannot be updated.
Also not all Tab values can be updated. See this answer for more information.
The putEnvelopeDocumentFields api is for a different purpose. Document fields are different from Tabs. Document fields are an array of name-value custom data strings to be added to a document. Custom document field information is returned in the status, but otherwise is not used by DocuSign.
I figured it out.
The "fields" we are seeing on documents are "tabs," and they are children of the recipients.
The hierarchy goes envelope > recipients > tabs, which tabs we were trying to change. Not envelope > document > fields, which refers to something else--just familiarizing with the language of the api.
Here is a link to the reference for how to change "fields" aka "tabs", and that link includes sample requests.
One thing that helped me target my actual fields, since I kept on getting an error that the field didn't exist for the recipient, is to do a get request of all available tabs and use that response body as the request body for the update call (where we change the field values). Then you know the field information will be accurate, paring the body down to exactly the "fields" aka "tabs" you are interested in targeting.
I have a template in docusign and can use it to create an envelope using all fields available.
The problem is one of the fields should be a table with a variable length of rows, so I cannot use auto placing because I don't know how many will exists upfront.
The only solution I found till now is to create a brand new word document and upload it to create the envelope, but this is causing problems since this document is taking at lest 10 seconds to be parsed by docusign, probably due to its size.
The best solution will be to have a template and it could be possible to send a "table" field.
Anyone got this before? Any suggestion is welcome.
Perhaps put the table on a second document that you create dynamically? Remember that an envelope can have multiple documents. The signing experience proceeds from one document to the next.
I have searched for current solutions, but can't find a set of guidelines or examples as to how to achieve the following:
The original requirements involved models with required fields, so we included annotations to those fields. As usual, there is a last-minute change and we are being asked to allow the users to save drafts. These drafts must allow the user to save the forms without any of the required fields.
I would like to know what the best practices for this problem are.
Solutions I am considering, but I accept they might be a hack (and that's why I am asking the experts)
If the user clicks "Save as Draft" I can capture the fields that have information in another ActionResult and run basic validation on those fields. Since there is a chance that required fields are missing, I am thinking in storing the captured info in a temporal model (without any required annotations). If the user decides to edit such form, I can populate fields in the view with the temp. model until the user clicks on "Submit"
Another option is to remove all required annotations and run client-side validations... but am wondering on the amount of work required to do so.
Any thoughts are very much appreciated.
Just have 2 save methods. 1 which is called from the autosave and 1 that is used to submit the process. In the autosave method do not check if(ModelState.IsValid).
Whether you choose to save the incomplete objects to the same table or a different table is your choice. In a relational world I would likely use a separate table, in a non-relational world I would use a singular object collection.
This will allow you to keep the same set of original models. There is a very high cost to duplicating your models, there are certainly times that warrants pass by value/copy but make sure the cost of mapping is there. In this situtation I do not believe there is value in mapping, except perhaps at the persistence level if you need to map to a different object because of an ORM's constraints.
There is deep value in these partial forms. Recording this on the server will allow you to apply analytics to learn why your users abandon your processes. It also gives you the ability to follow up on users who leave incomplete forms such as sending a reminder (nag) email.
You don't want to save anything to your database until it is complete. Having a duplicate table where everything is nullable is cludgy as hell. Before HTML5, the typical path was to save the information to the session, which you could then pull from to refill the fields, but that's requires having a session with a relatively high expiry to be useful.
Thankfully, HTML5 has local storage, which is really the best way to handle this now. You just watch for onchange events on your fields and then insert that value into local storage. If the user submits the form successfully, you destroy the local storage values. Otherwise, you attempt to read those values from local storage when the page loads and refill the fields.
See: http://diveintohtml5.info/storage.html
There's pretty broad support, so unless you need to worry about IE6 or IE7, you won't have any issues.
Another option (depending on your data obviously) would be to comply with the database but not the model. By this I mean ignore Model.isValid and disable Javascript validation on the front end but then satisfy the database table. In a form, you mostly have:
textboxes - default to "" or " "
checkboxes - easy true/false default
radio buttons - one is probably already selected
dates - default to DateTime.MinValue (or DateTimeUTC)
enums - default to 0 (usually for 'unspecified')
Hopefully you are also saving a flag designating that it is in Draft state so that you know you need to interpret the 'null codes' you have set when it comes to displaying the semi-populated form again.
Is there a standard way to associate custom properties with a user? I need to store the number of items per page a user selected in a grid of a document library separately for each user and document library.
Edit:
Sorry about this vagueness, I wanted to do it programmatically. It seems like I've found the solution, it is UserProfileManager class, though I'm now looking into whether there is a limitation on the number of properties you can save this way for a user, because the easiest way of saving page sizes on per user+document library basis seems to be using GUIDs of Views as property names and numbers of pages as values. Though I don't know if it is more efficient or not, depends on how sharepoint stores these properties.
No, you would need to create custom code to store the data.
Given the potential amount of data created, it may be wise to store it in a separate database.
This would give greater flexibility in the way the data can be manipulated and retrieved.
Your question is a bit vague. Are you looking to do any custom code? You could do this many ways so it is difficult without knowing more of what you want.
Using custom code you could set up a workflow or event handler to respond to item events and record the information and store it using the User's Profile or as an SPPersistedObject.
If you want a less developer centric way to do it you can use auditing and simply do reporting on your audit results.
You could set up a list to store the selection data, then use events/AJAX on the document list to push tick/untick items into the selection list (store user, library and document as a minimum.
If you don't want a separate list, you could create a field in your document library that stores which users have a given document tagged... You'll still need some kind of event/AJAX to update the list when a user ticks/unticks the box. Crude :)