Community
Showing results for 
Search instead for 
Do you mean 
Reply

Contact field OAuth queries and some assorted questions

Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Contact field OAuth queries and some assorted questions

  1. I know that further OAuth filtering is in the pipeline, but are you able give a rough ETA?
  2. Contact fields exclude either the IDStatus field or the SQL equivalent Category field, or am I missing it somewhere?
  3. Are there plans to extend the User entity to allow GET api/users listing all Users?
  4. How long is the Bearer token valid, does it require refreshing after some period of time?
  5. How does the API respond if the backend dB is locked for whatever reason?
  6. Will the API support getting Activties for a passed in USERID?
  7. Do the Contact fields use the alias field name or the display name?
  8. Are there any plans to allow us to carry out CRUD opperations on the schema/meta (i.e. get existing fields for an entity, create fields for an entity etc) I appreciate we can interrogate the entity for a list of fields but I'm really interested in puting fields.
  9. Should we expect Histories & Oppoerunities in the first service pack update?
  10. Will v18 installer include the Web API install with the std install, or will it require a seperate install?

Thanks.

 

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Employee
Posts: 236
Country: USA

Re: Contact field OAuth queries and some assorted questions

Wow, that's a lot of questions.  I'll answer a few that I can offhand:

 

1. I think you mean OData, and while I can't give you concrete dates, I can tell you we're actively working on delivering virtual field (address, email, phone) queries as we speak.  If there's something specifc you are looking for, let us know!

 

2.  Need to check on this one

 

3.  Nothing in the near term, but we are discussing how we can provision accross the porfolio in a standardized manner, which is a bit more than just managing users.  Stay tuned.

 

4.  Great question.  Currently I belive it's 1 hour, but basically you don't want to know that - what you want to do is use it until you get a 401 / Unauthorized response and then trade it in for a new token via the /authorize route.  We probalby need to better document this.  Also, there's currently affinity to the app pool currently - which means if you restart IIS or the app pool gets recycled, you'll need to authorize via credentials again.  We're fixing that.  

 

5.  I don't know the exact answer, but I would expect something similar to the SDK. Namely some error.  

 

6. That makes sense, though it's a bit complex as we try to crack this uniformily accross the portfolio (ie what that looks like for Essentials)

 

7.  I believe alias but need to make sure I'm accurate here

 

8.  Label / naming metadata certainly, actual field creation/update/deletion is a bit tricky via web api in a distributed environment.  Possibly?

 

9.  You should expect histories very soon, likely before v18.  

 

10. I think we will include it, the question is whether it should be installed by default.  Thoughts?

 

 

Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Re: Contact field OAuth queries and some assorted questions


Xavier wrote:

Wow, that's a lot of questions.  I'll answer a few that I can offhand:

 

1. I think you mean OData, and while I can't give you concrete dates, I can tell you we're actively working on delivering virtual field (address, email, phone) queries as we speak.  If there's something specifc you are looking for, let us know!

 

2.  Need to check on this one

 

3.  Nothing in the near term, but we are discussing how we can provision accross the porfolio in a standardized manner, which is a bit more than just managing users.  Stay tuned.

 

4.  Great question.  Currently I belive it's 1 hour, but basically you don't want to know that - what you want to do is use it until you get a 401 / Unauthorized response and then trade it in for a new token via the /authorize route.  We probalby need to better document this.  Also, there's currently affinity to the app pool currently - which means if you restart IIS or the app pool gets recycled, you'll need to authorize via credentials again.  We're fixing that.  

 

5.  I don't know the exact answer, but I would expect something similar to the SDK. Namely some error.  

 

6. That makes sense, though it's a bit complex as we try to crack this uniformily accross the portfolio (ie what that looks like for Essentials)

 

7.  I believe alias but need to make sure I'm accurate here

 

8.  Label / naming metadata certainly, actual field creation/update/deletion is a bit tricky via web api in a distributed environment.  Possibly?

 

9.  You should expect histories very soon, likely before v18.  

 

10. I think we will include it, the question is whether it should be installed by default.  Thoughts?

 

 


 

Thanks Xavier, sorry to have bombarded you with questions but I'm quite keen on trying to get up to speed as fast as I can since my web dev skills are appauling!

 

  1. Yes, sorry I did mean OData. I was hoping that the Web API would have a similar query notation as some of the early beta of Essentials that I had tried whereby we could qreate a query for almost any entity field. Would we be able to do a Narrow Down query via the API, or wouild we need to provision the logic our end?
  2. Cheers.
  3. I can imagine the task will be complex considering that the User object in the desktop product is a much more complex entity than in Essentials. I think at least if we can GET a Userlist that would be more conformant to the rest of the schema/std from my very basic understand?
  4. I presume then the best practice would be for our code to check for a 401 in a try-catch block and then call on the Authorize method to generate a token. Is it possible for a token to also have a time-stamp, or does that weaken the security model? I'm thinking of those moments when the Authorization occurs a milli-second before the token is refershed. If it happens relatively frequently it would lead to a poor UX for clients of 3rd party apps.
  5. Would it be possible for a custom error page to be returned or even a 401 or 404?
  6. Cool
  7. Ok cool, I was fearing it might be display whch could lead to issues in the future.
  8. This is quite an important thing for us 3rd parties especially when it comes to integration with other products. We may need to ensure the creation/existance of certain custom fields. If we cannot do that via the API, then we would require a more complex installation procedure with a 2-phase process one using the SDK and the second using the API. It just seems ugly to me!
  9. Awesome!
  10. I think it makes sense to include it with the install package. I suppose I understand some of the issues here especially if we throw in the Pro edition into the equation. If we have it as an option during install we would need some very easy way for a client to recognise that they do not have Web API implemented/installed to avoid them purchasing a WEB API app and burdening ours or your support. Will the API exclusively require IIS or could any web server be used? Again I appreciate this is a loaded question since it brings into topic the notion of platform independance!

 

Thanks for taking the time to look and answer these queries.

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Employee
Posts: 236
Country: USA

Re: Contact field OAuth queries and some assorted questions

These are good, hope they help everyone.

 

1.  Yep, you can filter (subset the data), that's there now.

 

2.  ID Status is there, it's just treated as a custom field (while it's in the stock schema, it's modifiable).  

 

4.  I believe tokens have both issued timestamp and expiration timestamp.  However, the expiration is when you can no longer trade a token for a new one, not when you need to refresh the token.  So to your point about poor UX, that wouldn't be applicable in the case of a token that just needs to be refreshed (which is the typical case). You trade in the old token for a new one, no user involvement.

 

5.  You'll get a 5xx error, with verbatim framework exception.  It might make sense for us to be a bit more specific here agree.

 

7.  It is aliasn, unles alias name is null, in which case we default to column name.

 

8.  Great point - it makes sense to expose this.  Consider it on the roadmap.

 

10.  Currently IIS is the assumed web server, and integration with Act! for Web.  Certainly there's the possibiliy to expand from there.

 

HTH