I'm creating a web application for manage a contacts with their appointments.
Every contact has a classic fields (name, email, telephone, etc) and a list of appointments (with date, scope, place, etc fields).
I have already implemented the back-end side. Now, I'm working for front-end side.
But I don't have idea what it could be the best user experience for manage this contacts.
Could you suggest me some idea? Thanks
Related
I am building an app utilizing the MERN stack (MongoDB, Express.js, React/Redux, Node.js) where there will be three user account types: Client, Company, Admin.
Client account can search and partner with Company accounts where they can submit orders.
Company account will be a paid subscription (via Stripe) where they can complete orders submitted by client accounts.
Admin will be an interface to view all users, orders, etc..
I am trying to determine the best approach for create multiple user account types in Mongo. I assume there will need to be two different registration forms. I'd like a single login form that will determine if an account is client or company and display relevant information based on their role.
Looking for input on the best/most scalable approach for this.
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
I am trying to figure out the best possible way to manage a system where we will be sending out different documents via the api through one account. These documents will need to be handled by different departments. Is there a way in the api to share the envelope with a particular group/user? My other idea was to create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user. It seems like a more complex solution but I know it would work.
Thanks,
Dan
I'm not sure why your question was downvoted without a reason, so I'll throw out my 2cents.
Question 1: Is there a way in the api to share the envelope with a particular group/user?
You can share all of a user's envelopes with group/user, but not specific envelopes. I do not suggest building a workflow around this.
Idea 2: Create multiple department API users and depending on which document I am sending will use that departments API user and associate that API user with the department user.
This is the best solution for scalability and customizibility, remember that an API user does not need to be an admin to create an envelope. In this case, it would be better if that user was not an admin, so they are limited to access only the envelopes that you'd want them to access.
I'm not sure what language your integration is in, but you should be able to store all of the credentials in an array/hash and just call the specific entry for username/password per workflow.
You didn't post what requirements you need for these workflows, so this is a very high level generic question and answer. You may want to go back to the drawing table and figure out your hard requirements. The solution above may not fit all of your requirements, especially if your security team has specific requirements that they need to have followed.
example requirements
Envelopes need to be created through the API
All envelopes must reside on the same account
Envelopes can't be seen by other departments
Envelopes need to be modified by department DepartmentName after Envelope Creation
The API needs access to view the status of these documents
Using Instagram's API, is there any way to request a list or count of an application's registered users?
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed, but I haven't found a way to get a list of those users, or even a count. This is easy enough to store server-side, but seems like something which should be discoverable.
Your Question
Using Instagram's API, is there any way to request a list of an application's registered users?
A quick search yielded no results for such a functionality. This make sense, though, since Instagram wouldn't want to open up all its users to any app designer.
Your App
If you want the number of users using your app, then you can easily track this yourself.
Instagram App
As mentioned before, Instagram probably won't provide even basic count information about its registered users. Presumably, this is valuable information.
Your Example
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed...
This is true, but with very limited scope. The subscriptions below are based on users who are using your app or other simple criteria such as tags or geographic data.
Users: receive notifications when users who have registered with your application post new photos.
Tags: receive notifications when a new photo is tagged with tags of your choosing
Locations: receive notifications when new photos are posted and tagged with a specific location
Geographies: receive notifications when a new photos are posted in an arbitrary geographical location as defined by a center point
and radius
As far as I have found this far there is no IG API, however as already indicated you can keep track on your app. HOWEVER, what has not been pointed out is that you won't be made aware if users terminate their account or revoke your app so the count's might be a little off. (or worse if you didnt start keeping track since the public launch of your app)
You could test on a periodic basis if you still have access, but that would require additional code, and a lot of API calls if you app has a lot of users. I hope that IG will add this function at some point.
Requesting the roster via XMPP just gives me a list of all friends. Is there a way to request or determine with users are online (as well as their active / idle status) at the time of the request? I'm using the X-facebook-platform authentication mechanism to fetch only the online facebook friends list.
Please help..
Thanks
There is no way to request only online users. The XMPP server will return the entire roster with status information. You would then query the roster module for the online users. The concept is similar to the sample apps, which sort by status and display the users in a table view.