Will do.

I'd say the default behavior should be #1, to generate a unique slug for the imported collection.

Commenting here since this affects all the child tasks:

last one, I promise. next time I'll use the mocks.

if using unclaimed works, how does this help sound?

what about using unclaimed for the local unsynced posts in this list?

ok cool, I'll make the change

As for terminology, I would say we should have "synced" vs "unsynced" for our release, just so we don't confuse people. Maybe the title then is "Status" instead of "Location"

Here's a library I built to start this rolling: https://github.com/writeas/zip-import

I think for this one, it will be both.

pinged the wrong matt on the PR for this. Also should be open until that is merged.

this is already implemented as NewClientWith

I also put up #30 CLI which returns the errors during delete to the user. Then this can close.

TODO: is this WF only? Or both CLIs?

TODO: is this WF-only? Or both CLIs?

In T594#9289, @robjloranger wrote:

this will be set on the writefreely cli, the writeas cli will retain the original .writeas directory

Created WriteFreely CLI, so it's easier to track features that should be in only one client (or both). In this case, this is a WF CLI feature only.

Created WriteFreely CLI, so it's easier to track features that should be in only one client (or both). In this case, this is a WF CLI feature only.

Assuming the #117 fix works in your testing, after reviewing everything I do think this is the right solution.

This is required to test the fix for T612 on the WriteFreely side

I think I found the issue, the logic in this function on writefreely appears to check first if the accesstoken or user were found and proceed with that authentication, which will result in no affected rows. Lines 741-788, then an else which assumes the editToken instead.

I found in go-writeas:

Just to mention, here's some prior art on publishing text files via the API: https://github.com/writeas/writeas-api/tree/master/examples/go-text-importer

This might be good to do in the near future -- certainly before v1.0 -- because of how much easier it'd make the setup process.

I'd say the assumed behavior will be that all posts are imported. This is the behavior on the web app, and will be the behavior on the Android app, as well.

Can you verify requests (both login and delete) are going to the right environment with some logging on your end? If they are, I'll add some logging on the dev server.

Not crucial in the short-term.

Not crucial in the short-term.