Creating issue fails if assigned and mapped user has no write access to repo

[vornkat-iis]

TLDR; Issues are numbered wrong after import because for some issues the import fails because the assigned user has no write access to the private repo.

What I want to do: Import metadata (issues, MRs,...) to a private GitHub repo, check everything and publish once it is tidy. Map and link the respective users to give them credit, even if they are no more actively contributing.

What I expect: All issues appear and are numbered the same way, so links e.g., from commits mentioning them, point to the correct issue in GitHub.

What actually happens: Issues which failed to create are skipped, messing up the numbering for all following issues.

Proposed solution: If creating the issue fails because the assigned user does not have write access, create the issues anyway but without assigned user. I assume this means parsing the error, adjusting the parameters and calling the API again.

Unfortunately it is not possible to give everybody write access to avoid this.

Console Output

``` Migrating issue #3 ('')... Migrating issue comments... ...Done creating comments (migrated 1 comments, skipped 4 comments) FAILED: { status: 200, url: '['](), headers: { 'access-control-allow-origin': '*', 'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset', 'cache-control': 'private, max-age=60, s-maxage=60', connection: 'close', 'content-encoding': 'gzip', 'content-security-policy': "default-src 'none'", 'content-type': 'application/json; charset=utf-8', date: 'Wed, 12 Jul 2023 18:47:44 GMT', etag: 'W/"<...>"', 'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin', server: 'GitHub.com', 'strict-transport-security': 'max-age=31536000; includeSubdomains; preload', 'transfer-encoding': 'chunked', vary: 'Accept, Authorization, Cookie, X-GitHub-OTP, Accept-Encoding, Accept, X-Requested-With', 'x-accepted-oauth-scopes': '', 'x-content-type-options': 'nosniff', 'x-frame-options': 'deny', 'x-github-api-version-selected': '2022-11-28', 'x-github-media-type': 'github.v3; param=golden-comet-preview; format=json', 'x-github-request-id': '0430:9958:2F1A2F0:2F75C4B:64AEF550', 'x-oauth-scopes': 'admin:enterprise, admin:gpg_key, admin:org, admin:org_hook, admin:public_key, admin:repo_hook, admin:ssh_signing_key, audit_log, codespace, delete:packages, delete_repo, gist, notifications, project, repo, user, workflow, write:discussion, write:packages', 'x-ratelimit-limit': '5000', 'x-ratelimit-remaining': '4846', 'x-ratelimit-reset': '1689189718', 'x-ratelimit-resource': 'core', 'x-ratelimit-used': '154', 'x-xss-protection': '0' }, data: { id: 7812881, status: 'failed', url: '['](), import_issues_url: '['](), repository_url: '['](), created_at: '2023-07-12T20:47:42.000+02:00', updated_at: '2023-07-12T20:47:42.000+02:00', errors: [ [Object] ] } } ERRORS: [ { location: '/issue/assignee', resource: 'Issue', field: 'assignee', value: 'fraunhofer-iis-anon', code: 'invalid' } ] ...DONE migrating issue #3.**** ```

[roharvey]

I just ran into this, and indeed the issue number was off by the number of non-imported issues. I sort of wonder if the issue number is simply an incrementing counter (and I'm not sure what happens if there is a deleted/non-sequential issue). I ended up re-imported some issues (unfortunately GitHub doesn't allow you to delete via the API in order to restart). Would have been ideal for this to continue to import and simply add a comment that user A was unassigned from the issue.