I can't seem to find any way in the Quire API doc to mark a task as unread (i.e. appearing with a red/orange dot next to it in the Quire app). If it does not exist, it would be a useful feature to implement in order to allow the user to detect a change made through the Quire API.
Best regards,
Rafaël
The "unread" indicator behaves in the same way when using the quire-api/browser or mobile clients. It shows when a new task or comment was added by another user, through either UI or api.
Neither the UI nor the quire API have a function to explicitly control this status indicator.
So as of now it would not just be a "new/missing" api feature first, it's rather a new completely new Quire-Feature, which had to be implemented first. You can post your feedback and ideas in the Quire Feedback project (keyword 'orange dot') or send an email to info#quire.io / support#quire.io.
So as of now you can trigger this by adding a comment or add a new task via API.
A workaround I found is to add a new task and to set asUseras true as explained in https://quire.io/dev/api/#operation--task-id--projectId--post. Then, the task will be marked as unread
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.
Good afternoon,
I am integrating DocuSign into our business applications (node.js) and have an issue:
Is there a way to use the DocuSign connect webhook to let me know when a workflow is paused? On the admin connect page, I have all possible boxes checked on the connect options - which do not include anything about workflow status (mostly signed/delivered/completed/declined stuff).
My current workaround is to add a customField on the Signer 'pauseAfterSigned' which I check for in the webhook xml. If the signer with that field has Status "Completed" then I know the workflow has been paused. This seems like a lousy workaround :(
We currently don't have an event fired when a workflow is paused as far as I know. So your workaround would have to do for now. Can you please provide more information around your scenario? Perhaps it's something we should consider adding depending on the scenario here. Thank you.
We are using a read only Asana "Project" to manage our design work. Our design work is organized as Asana Tasks. Each Task represents a different design project. The reason for making it read only is to limit Asana users from accidentally making changes to the project details and to restrict Asana users from creating their own tasks that fall outside of the Task standard structure that we have decided on.
To create these tasks in Asana we are using a combination of Cognito forms and Zapier to create the tasks automatically. Our customer fills out the Cognito form and Zapier automatically populates Asana with the design Task that needs to be completed for that specific customer.
The issue with this setup is that to move the tasks around in Asana to provide the team with "updates", either an Asana user with write privileges needs to do it, or the Asana user needs to fill out a form to make the change, since they only have read privileges. We would prefer to keep it super simple and I have figured out a way to do it using Zapier webhooks.
Because we are using Zapier, I can format URL links in any sort of way I want. I can create a URL link that includes the Asana Task ID and the Asana section that the task needs to be moved to. Using webhooks, a user can click a "Change Section" URL. Clicking this URL will trigger a Zapier Zap action which then will change the Asana Task Section. Just by clicking the link a User can make updates to that task.
My question is fairly basic. Is there a way to stop the URL from opening a page but for the data in the URL to be still passed to Zapier? When a user clicks the link it opens a web page and I don't want that to happen. Or if it happens, could the web page immediately close after opening?
The short answers is "no, it's not possible to click on a zapier link and have the page not open or auto-close" out of the box.
The long answer is a little more involved. I'm assuming your url looks something like https://hooks.zapier.com/hooks/catch/1234/abcd?name=john&cool=true, allowing you to pass "name" and "cool" into Zapier.
To pass that into Zapier, you need to get the contents of that URL, either by loading it in a web browser or calling it with another tool (such as fetch or curl).
If you've got some engineering resources, you could host a very simple HTML page somewhere that could accept data and run some Javascript. It would do something like:
read Zapier webhook url from the querystring (probably worth encoding)
On pageload, run await fetch(thatUrl)
Instruct the user to close the page (which is better UX than the JSON or black response you get from Zapier). I thought JS could close any page, but it turns out window.close() only works if the script opened the page (docs).
So that's an ok workaround.
Am looking for some help in a subscription service email sending from domino using Xpages.
scenario : Paul Goodman is a building contractor and he would like to subscribe to his category named "Buildings and Road”.
When someone asks question about his category "Buildings and Road” he and everyone else that have the same subscription , should get email. I have a LS Agent that goes thought a view to send these emails but I would like
to have his done as soon as the message is saved and it has to send one at the time to void spam filters. I know I could execute the LS agent onSave but do you see another solution maybe with JavaScript ? I have only seen some .NET & PHP solutions here.
You have a series of options here:
Extract your logic into a LS library, so it can be used by several agents. Then have on that runs on save (and another one on a new subscription)
Use a DOTs task to listen to documents save - you can write your logic in Java then
Call an ?OpenAgent URL from your client side JavaScript
Put it into your XPage for new articles
Since you have the agent already, I'd go with the first one
I have this scenario:
A user follows a feed and they receive all of that feed's current posts as new posts (via realtime notification.. likely caused by a fanout)
While its accurate that all that feed's items are new to the follower, I'd like to stop the notification from appearing..Is it possible to disable the fanout notification when a feed follows another?
We don't currently have a way to suppress realtime notifications upon follow. The only way I think you could accomplish this would be for User A to follow User B without copying any old items, but then User A would only see new activities going forward.
I'll mention this to the team as a feature request.