When using idtlist I see goals for all members of the team, not just my goals

[lkngtn]

This seems to be unintended, and possibly a simple fix?

[jeffbyrnes]

Oh no! When I wrote this functionality, I was the only member on my “team”, so I never came across this. I’ll try to fix this tomorrow, but if you’re game to dig in yourself, pull requests are always welcome.

The API call needs to be altered, or filtered, so it only shows you your own goals.

[lkngtn]

Thanks for the quick reply @jeffbyrnes

I took a quick stab at getting it to work by updated the scriptfilter in Alfred, but was unsuccessful.

[jeffbyrnes]

@lkngtn I’ll need your help testing this out. There are two endpoints for listing entries:

• List Entries
• List Team Entries

The former allows you to “…restrict to showing entries for a particular team…”, so that may be what we want to use. At the moment, I’m using the latter API endpoint.

Is there any chance you can make a request to each of these endpoints, and see if the first one just shows your entries, vs. the second one showing your entire team’s entries?

[chadhs]

@jeffbyrnes @lkngtn if you guys get this solved and tested I'll be quick about the PR review 👍

[lkngtn]

@jeffbyrnes I tested by changing the following line in the scriptfilter:

from: uri = URI "#{base_uri}/teams/#{team_id}/entries" to: uri = URI "#{base_uri}/entries"

The result was the same in both cases. Based on the API doc it looks like entries would give you all entries across all of your teams, and the team id gives me all entries for that specific team. Since I'm a member of just one team the result is equivalent, but still not what we are looking for.

The "Entries" object has a "User" field with a related "hash_id" value. When I tried getting this to work locally yesterday, I attempted to filter the returned results so that the user hash_id equaled the hash value I saw in the URL for my user profile, but that did not seem to work as intended, though I suspect that could be simply an issue with how I hacked the filter (I'm not familiar with ruby at all) and not a problem with the approach.

[jeffbyrnes]

Darn. I’ll have to dig into this User field and its hash_id and see if we can filter on that.

[jeffbyrnes]

@lkngtn I’ve pushed up a branch, with an updated alfredworkflow in it. Would you try that out & see how it goes? You’ll have to edit a new env var in the workflow upon installation: the email address used in your I Done This account (I could not see a way for an end user to easily get their hash_id).

[lkngtn]

Hey @jeffbyrnes thanks for pushing the change, unfortunately still not able to get it working. After removing the old version, and installing the new workflow I get a null list (despite having active goals). After adding a new goal, and trying again I saw an error about the cache being missing.

Here is the debug output from that process:

Starting debug for 'I Done This for Alfred'

[2017-10-20 11:18:20][input.scriptfilter] Queuing argument '(null)' [2017-10-20 11:18:20][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 11:18:20][input.scriptfilter] {"items":[]} [2017-10-20 11:20:57][input.scriptfilter] Queuing argument '(null)' [2017-10-20 11:20:57][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 11:20:57][input.scriptfilter] {"items":[]} [2017-10-20 11:22:53][input.scriptfilter] Queuing argument '(null)' [2017-10-20 11:22:53][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 11:22:53][input.scriptfilter] {"items":[{"title":"Error","subtitle":"No such file or directory - /Users/luke/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/com.chadhs.alfredapp.idonethis/1/0/10ae9fc7d453b0dd525d0edf2ede7961"}]} [2017-10-20 11:22:57][input.scriptfilter] Processing output of 'action.script' with arg '' [2017-10-20 11:23:02][input.scriptfilter] Queuing argument '(null)' [2017-10-20 11:23:08][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 11:23:08][input.scriptfilter] {"items":[]}

[jeffbyrnes]

Blast. I tweaked the cache code a bit, but it seems that backfired. I’ll unroll that.

[jeffbyrnes]

@lkngtn ok, I’ve rebased that branch, and it should now only contain changes that add the email_address filtering. Please try once more?

[lkngtn]

@jeffbyrnes Tried again with the new branch, didn't get the cache issue but still seeing an empty list even after adding a fresh goal. Is this working for you? Perhaps its something specific with my idonethis account?

debug:

Starting debug for 'I Done This for Alfred'

[2017-10-20 13:22:40][input.scriptfilter] Queuing argument '(null)' [2017-10-20 13:22:40][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 13:22:40][input.scriptfilter] {"items":[]} [2017-10-20 13:23:12][input.keyword] Processing output of 'action.script' with arg 'test idtentry from alfred' [2017-10-20 13:23:12][action.script] Processing output of 'output.notification' with arg '"test idtentry from alfred" has been posted. ' [2017-10-20 13:23:27][input.keyword] Processing output of 'action.script' with arg '[] test goal entry from alfred' [2017-10-20 13:23:28][action.script] Processing output of 'output.notification' with arg '"[] test goal entry from alfred" has been posted. ' [2017-10-20 13:23:34][input.scriptfilter] Queuing argument '(null)' [2017-10-20 13:23:34][input.scriptfilter] Script with argument '(null)' finished [2017-10-20 13:23:34][input.scriptfilter] {"items":[]}

[jeffbyrnes]

@lkngtn well, now I can’t seem to get it to work any which way. That is, the old code also no longer works.

[jeffbyrnes]

@lkngtn well this is disappointing: that API call no longer appears to provide goals. I just scanned through the raw response, and it lacks any entries with "status": "done".

@chadhs, any chance you can look into that for us?

[chadhs]

@jeffbyrnes @lkngtn I'm able to add goals, see a list of them, and mark them as done successfully with the current release of the workflow; however it seems using the API vs the UI has different behavior for marking them done see the attached image.

so i think we'd have to dive into the response fetching these and seeing the difference in the data returned.

i'm hoping this is doable, but is not a simple fix and could require hitting up the iDoneThis team as well.

i'm short on free time, but will add it to my list to look at in case one of you guys don't beat me to it. :-)

[lkngtn]

@chadhs @jeffbyrnes I can confirm that with the original workflow it does return goals, though the returned goals did not seem to be as expected. In some cases it would return goals for a different member of the team, and right now it seems to be returning my personal goals but only a partial list of recent added goals.

I'm not sure what causes the inconsistency, will see if I can provide better reproduction steps.

[lkngtn]

Not sure how this happened, but it seems that @jeffbyrnes original suggestion seems to resolve this issue. After playing around with the api endpoints it appears that the Entries end point does actually just return the authenticated users entries. Sorry for the trouble caused by not correctly validating that days ago!

I submitted a PR with the change to the uri and a binary export of the workflow. #16

The other odd behavior, only getting a partial list of entries seems to be due to the api only returning 25 entries. So if a goal was not created in the last 25 entries it will not be returned at all, but that seems like its a separate issue.

[jeffbyrnes]

The API returning only the last 25, I wonder if it’s paged… @chadhs, any chance you can look into that for us?

Also, it’d be super great if the docs could be updated to reflect the difference between the two endpoints. I submitted two suggestions via Readme.io.