This is a common problem that I find when programming a Lotus Notes App.
Use case: An employer fills out a request form in a Request database. A notification gets mailed to the person that may give them OK or REJECT for that request. The authority person visits the Request database and gives OK or REJECT.
Good. But, where would you save the approval status OK or REJECT:
Should the authority person have write access to the original request
and set the status directly (and may alter other data in the form)
Should the aproval action create a response doc to the original (and i cannot show in a view the current status)
Typically you are better off setting an approval status directly on the request. That may not seem initially ideal, but remember Lotus Notes isn't like a relational database where things would be more normalized.
Let's consider the alternative, putting a status in the response document. Now how do you show all the requests with their statuses? You'd probably have to write some code just to do that when with the first option you could just create a view.
You can control the access to the document using reader and writer access fields. See how the built in template does it (the approval workflow template). Essentially as the document changes state (i.e. New, Submitted for Approval, Approved or Denied, etc), you can also change the reader and writer access fields at that point.
Once, I designed a database that mailed that request to the approver with the form stored in the document. As long as the user accessed the document using a Notes client, they could click on a button in the message to approve, which would send a message back to the database with the field data to mark the request as approved. An agent in that request database was set to run when new mail arrived, read those messages and change status on the original requests. That way, the approver never had to leave their inbox and didn't even need rights to edit the request.
You could do it with URLs if the users would be approving via browser client - have the link to an agent and pass in the parameters.
Or, to go back to your scenario, once the requester has submitted the request, don't display the fields that you don't want changed, display the values as computed text instead.
Anyway you look at it, best to have the approval recorded on the original document.
For above, Everything is our concern. In SQL or any other RDMS, we are in need of normalize that. Similarly here we have view categorization, show response document in hierarchy, and a lot of great hide when functionality based on role, ACL, unique person and whatever you need. We can easily manipulate the data render depends on the current user.
For your Q:-
1. We can control the appropriate user[authority person] from editing the request form's item.
2. We can also do by the response document. There we can show the documents in view by using show the Response documents in hierarchy.
Related
Scenario:
My application dynamically generates a contract (PDF) on-the-fly through the use of some base language and replacement variables from user data. That pdf is then sent to the DocuSign REST API with the list of recipients/signers/tabs which handles delivery of the agreement to the various parties.
Issue:
At times during the negotiation process for the contract, users may need to make edits to the agreement. My application has a correction interface where they're able to regenerate the original PDF and then have an action that allows them to update the existing envelope.
To perform these corrections, I'm currently using the following API Calls for a single correction:
getEnvelope to retrieve the current status and make sure the envelope hasn't been voided, completed, etc.
deleteEnvelopeDocuments to remove all existing documents.
updateDocuments to send the base64 encoded document to the envelope.
updateEnvelope to send the recipients back to the envelope because they're deleted as a result to #2.
These 4 API calls feel like a mistake to me because if any one of them fails for whatever reason, the entire process fails. In addition, the processing time for the back-and-forth is also a consideration even though I could delegate that to a queue'd background process.
My Question (I know, finally)
Is there a better way to do what I'm trying to do? Perhaps I can skip #1 and just catch an exception thrown by DocuSign when attempting to update a completed / voided envelope. What I'm really interested in knowing is if I can consolidate #2-4 into a single call somehow. The API doesn't feel super clear on corrections and also doesn't send any notifications when an envelope is updated via the API.
I think this can be done with two API calls instead of four.
You can make a PUT call to replace a document
PUT .../envelopes/<envID>/documents/1
This API replaces an existing document, there's no need to do 2+3 separately.
This would eliminate the need to do #4 as well, because the tabs (not recipients as you stated) are not going to be removed if you don't delete the document but simply update it.
I have create a form in Notes Designer version 9.0 and i am unable to forward this form to any users, as i do not find Forward Button under Create Menu.
Not sure if am looking at right options to forward the form, please help.
Thank You
Venu
There are two classic approaches to publishing a form for users to fill out.
Set the Store Form in Document property on the form (see here), and add mail fields (SendTo, Subject, etc.) to it. Add a button that is only visible to you and use #MailSend code in that button to send a document to the people you want to fill out the form. Add another button that is visible to the recipients, and use #MailSend code in that button to send the document back to you, or to a mail-in database. The form will accompany the document wherever it goes. (It will be stored in a field called $Form.)
Just put the form in a database on your server, and set the ACL so that your users can create documents in that database. Send an email message to all the users containing a button with code that executes #Command([Compose]...) with the options set to point to the correct server, database, and form.
Note that both of the above techniques assume that the people you want to fill out the form have Notes clients. If that's not the case, then what you'll want to do is this:
Just put the form in a database on a server that is running the Domino http task, and set the ACL so that your users can create documents in that database. Send an email message to all the users containing a link in the form http://server/path/databasename.nsf/formname?OpenForm
I want to make sure I am on the right track as I have been having some problems getting started with the API. I am looking to maintain a list of product application PDFs as templates on docusign. When a customer comes to our site and wants a particular product they need to fill out an application form. All the data would be collected on our site. I would then want to:
Create an envolope with the customer (and potentially other parties) that need to sign the document
Fill in the form fields from data collected on our site
Send the envelope out for signature and monitor the progress.
So in doing this I am trying to build this up a piece at a time and first task is to make sure that I can provide form data to docusign. I create a template with the docusign web user interface and all of the form fields seem to be preserved. However when I try and retrieve the template with API
https://demo.docusign.net/restapi/v2/accounts/xxxx/templates/yyyy
I see a very short response with an envelopeTemplateDefinition showing the correct name for the template but no documents object and no custom fields object. I have also tried this by creating an envelope with the document (in draft) but with similar results.
My apologies in advance for this newbie question.
I've repro'd the issue you describe -- i.e., the Response I get from a GET Template request contains only very limited information and is thereby not consistent with the expected Response as documented on pages 194-196 of the DocuSign REST API guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf). Not sure if this is a bug with the GET Template operation or with the Documentation -- someone at DocuSign will need to confirm (#Ergin).
In light of this limitation with the GET Template operation, you can alternatively retrieve the recipient information (including tabs) and document information about a Template by using the GET Envelope Recipients and GET Envelope Documents operations -- just specify the TEMPLATE Id in place of the Envelope Id, as shown here:
GET https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes/{templateId}/documents
GET https://{{env}}.docusign.net/restapi/{{version}}/accounts/{{acctId}}/envelopes/{templateId}/recipients?include_tabs=true
I have this sample application regarding Change Requests.
If the form is saved, it will send a form as an email to the listed approvers.
The form has 2 actions - Approve and Reject.
Let's say the approver approves the CR. It will update the emailed form document but the document that resides in my local database won't. Is there a way for me to update the documents in my local database automatically if the recipient(approver) has approved/rejected the document form?
Not automatically, but you can add logic to the approve and reject actions to update the database.
If this database is shared on a server, one way would be to make it a mail-in database. Your approval actions could then trigger an email that goes to that mail-in database address. Your database would then need an agent to process the emails, perhaps simply just parsing the subject line which could contain the UNID or some key that says which document to update along with the response of approved or rejected. This would work in a distributed environment.
If the environment is not distributed, say everyone is always on the same network connected to the same Notes server, then you could write some Lotusscript code to update the remote database directly.
Remember the context that you'll be in. When the emailed form is open in an approvers Notes client, he or she doesn't have access to your local databases. So you'll need to have a place on the server that the response action can update.
The safest design for a highly distributed workflow application, (replicas on multiple servers and local replicas on users laptops) is to have the approvals and updates posted as new responses and not have updates directly to the main WF document. The WF document should then compute the statues based on the responses. Finally, an agent running on ONE server can post the status updates to the document and archive the responses.
This construct will eliminate (or reduce significantly) the possibility of replication and save conflicts. It is particularly needed for WF items that require multiple approvals from people who are disconnected or connected to different servers.
I've got some nice little LotusScript that I can put into the Click event of an Action Hotspot in a rich text field when I'm sending an email manually. Is there a way to programmatically create that in the UI?
My script determines the user's home server and then opens a specific document in the replica of a training database on their home server. I could create these messages with hotspots manually and provide them to the folks who want to email them out. Of course, time being money and the task being boring, I'd rather automate it. I know that I could do this by using a stored form, but am wondering if the greater capability exists, as I can see further applications for it.
One trick I used in the past was to create a profile document in a database, and store some rich text in a field on that profile doc. Then when I needed to programmatically send an email, I could get that rich text field from the profile doc and use AppendRTItem to get it into the body of an email. That should work with any type of rich text, including hotspots.
Note: this won't work in the UI to populate a new email. It does work if you are generating the emails completely in code, though.