/summary. Will be live in a couple minutes. The value is
null when the User has no reviews scheduled.
Meaning either the user has never done any lessons or all active items have been burned?
And what if vacation mode is enabled? Will the next review date get pushed forward each hour?
Good question. In that scenario it should be
null. Will do a hotfix for this now.
summary endpoint has been updated in my docs.
Also, under the
lessons fields, all the objects in the collection will return an empty array for
subject_ids if the user is on vacation.
Hotfix is live now.
I found a few kanji that have
amalgamation_subject_ids that don’t point to a valid
kanji "川" amalgamation id 6390 doesn't exist kanji "広" amalgamation id 4378 doesn't exist kanji "図" amalgamation id 7633 doesn't exist kanji "相" amalgamation id 7633 doesn't exist kanji "面" amalgamation id 3877 doesn't exist kanji "堀" amalgamation id 6390 doesn't exist
I checked if they were hidden items, and it doesn’t look like it.
Thanks for the info.
I think I figured out the issue. Looks like those amalgamations are not visible to the user (role restricted). I’ll fix the scoping and will let you know when those kanji records get updated.
The fix is now live.
Hi @viet, do I have it right that there is no way to uniquely identify a user via the API?
When I fetch a user, I get their WK community username and their API key, but users can change their username and regenerate their API key. I want to allow people to change the API key in KameSame.com but I’m worried about the off-chance that they change the key to point to a totally different WK account, which could put their data in an indeterminate state (e.g. they have hundreds or thousands of different assignments than the other account did, I’ll have to figure out what to do).
Any chance we can get an ID or UUID for each user so we can be sure that a key reset isn’t changing their account identity?
The account creation timestamp in /user should be as unique as you’d need. If they change API key, and the creation date doesn’t match, you know they entered a different account. (A uuid would be the normal solution, though, of course)
That is a fair use-case.
I’ll write a quick spec for this, but can only promise a response to this early next month. Just want to run it by the other (developer) half first.
hah, nice lifehack
But it’s easy to generate the url:
Is there a way to see when a review was last failed?
Nothing very straight forward. You’d have to grab the
/reviews endpoint and sort through the reviews.
Ok, I think I see it. Correct me if I’m wrong, the review objects are snapshots, not the state of a single card. I assumed the values were overridden.