Workspace Changes

Comments

15 comments

  • Avatar
    Jeremy W

    Also, can you elaborate on each item a bit?

    {
    "change_type": "C",
    "created_at": "SOME_ISO8601_TIME",
    "resource_type": "Estimate",
    "created_by": some_int,
    "resource_id": some_int,
    "item_id": some_int,
    "type": "Change",
    "id": some_int
    }

    1. is there a difference between change_type and type?
    2. difference between resource_id and item_id?
    3. can I use "id" for a lookup to something else and get more info?
    4. is "created_by" always a member?

     

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Jeremy, 

    You are right, the workspace changes output does not include the change itself and the webhooks are the preferred method for getting the changes. Are you interested in any specific type of changes? For example, if you are looking for estimate changes, you can get a better picture by querying a specific task https://app.liquidplanner.com/api/v1/workspaces/xxxxx/tasks/xxxxxx?include=estimates  

    0
    Comment actions Permalink
  • Avatar
    Jeremy W

    Hi Nadia!  If I hit that endpoint, it won't give me changes but just a current state, correct

    Also, if I use the webhook, how can I reconcile if I've missed some activity because my listener tipped over temporarily?

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Your new questions came in as I was typing my response :) 

    1. Yes. Change_type can be "C" for create, "U" for update, or "D" for Delete.

    2. Yes. Resource id is the Id of the affected resource indicated by resource_type. In your example, resource_type is Estimate, so resource id is the estimate id. Item id is the LP ID of the item (task, event, etc.) that is associated with that resource. 

    3. You can use item_id to look up the item, for example /api/v1/workspaces/:workspace_id/treeitems/:item_id

    4. Created_by is usually a workspace member - in that case you'll see member_id in there. When the member information is unavailable or the change was made by the system, you may see a negative number there

    0
    Comment actions Permalink
  • Avatar
    Jeremy W
    1. You responded "yes" but didn't tell me the difference between "change_type" and "type" :)
    2. It's a little difficult to know what are the possibilities for resource_type and item.  Are they enumerated somewhere?
    3. ok.  Are estimates or other resource types NOT tree items?
    4. So if I filter on > 0 I'm good there.
    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Hi Jeremy, 

     

    1. Sorry. :)  The type is just the type of this particular resource, so if you query the changes endpoint, every record you get back will be of type "change". 

    2. You can see all available types here: https://app.liquidplanner.com/api/help/types

    3. Only some resources are tree items but not all.  Treeitems include Tasks, Events, Milestones, Packages, Projects, and Folders. See Treeitems Data Model for more info. 

    Regarding webhooks, if your listener has a problem, we retry the webhook 10 times and then disable it if still can't reach the webhook URL. You will receive an email notification about it. To get the missing data, you could query the changes endpoint but it has limitations. I recommend setting up two webhooks for the same event with URLs on different domains (one can be pointing to a webhook testing app, for instance) so that you have a backup elsewhere in case something happens to your webhook listener. 

    0
    Comment actions Permalink
  • Avatar
    Jeremy W
    1. ok, that makes my life a bit easier. :)
    2. link gives me 404
    3. will examine tree model more closely
    4. How rapidly does the webhook retry?  is there back-off? like 1 second, then 3 seconds, then 7...

     

    I really appreciate your help/answers!

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Oops, an extra space snuck into the URL - I fixed it. 

    I think there is back-off but I am not sure what it is. Let me find out and get back to you. 

    0
    Comment actions Permalink
  • Avatar
    Jeremy W

    ok, I'll wait back to hear from you on the back-off.

    0
    Comment actions Permalink
  • Avatar
    Jeremy W

    Also, with regard to the "changes" endpoint...There currently is a "since" parameter and then a "limit" parameter, but this gets a little messy with processing date vs count.  Could a parameter be added to compliment "since" and have it be called something like "until" that would provide an end timestamp?  This would make processing easier too and seems like it might not be too large of a change for the devs.

    0
    Comment actions Permalink
  • Avatar
    Jeremy W

    So are treeitems a proper subset of resources?  What I don't understand is why some changes have a resource_id different than the item_id.  What would be an example of that happening?  It seems like whatever you're editing would be the same id?

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Hi Jeremy, 

    1. Regarding the backoff, I confirmed that we do use backoffs and they follow a 2^(# failures) curve. So first failure would delay 1 second, next 2, next 4, 8, 16 etc. We ALSO have a cut off for sequential fails of 10. While the backoff is based on the URL (not a specific event dispatch) a bulk of updates can get scheduled together and hit the cut off first. (For example, multi
    selecting and re-assigning 10 tasks that notify a failing endpoint will immediately disable the webhook.

    2. The problem with the Changes endpoint is that the resulting change events are sorted in the descending order by date. This means that we are always returning up to 1000 most recent changes, no matter what your "since" date is. We are going to change that to ascending order so that you can get the first 1000 changes since the failure date, then get the date off the latest change and query again for the next 1000 changes, etc. I'll let you know when it's fixed. I'll also pass your request for the "until" parameter. 

    3. Treeitem is a type of resource. Any resource will have a resource ID. For example, member resource will have person_id as their resource_id.  Item ID is a resource ID on a treeitem (and Treeitems include Tasks, Events, Milestones, Packages, Projects, and Folders.) So if you are looking at a change for a task, your resource_id and item_id are the same number. If you are looking at a change for an Estimate, your resource is an Estimate on a Treeitem (such as a task), so it will have a resource_id (in other words, estimate ID) and an item_id of the associated task. 

    0
    Comment actions Permalink
  • Avatar
    Jeremy W

    I appreciate your diligence in finding things out for me!

    2. What kind of timeframe could a fix for correct sorting occur? Weeks, months, longer?

    3. Could you explain how to use the API for grabbing the info for a timesheet entry?  It doesn't seem very straightforward.

    Also, perhaps it'd be easier to communicate via email or something too because I'd like to not post specific id's, etc here on the forum.

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    You are welcome! I don't have an ETA on the sorting bug fix at the moment but I believe it is a few weeks away. I'll let you know when I have more information.

    Timesheet entries are filtered with URL parameters as described here: https://developer.liquidplanner.com/docs/timesheet-entries

    I think it's a great idea to continue via email so that we can dive even deeper into details. Please email to my attention at support@liquidplanner.com

    Thanks! 

    0
    Comment actions Permalink
  • Avatar
    Nadia Welter

    Jeremy, I wanted to give you a quick update on this thread to let you know that we fixed the order of data returned by  workspace changes requests. Now the changes are returned in the ascending order so you get the changes since the date/time you specify with the 'since' parameter up to the limit you specify. 

    0
    Comment actions Permalink

Please sign in to leave a comment.