Allow users to add an issue/PR to a board in a different organization

[timrogers]

At present, this Action only supports adding an issue or pull request to a project in the same organization as the issue or pull request itself.

This removes that limitation. If the issue/pull request and project have different owners, then instead of directly creating a project item, we will instead create a "draft issue" which will be added to the board.

Fixes #74.

Note that there are pre-existing failing tests in this branch which fail even before my code changes - see #140 for details.

[mattcosta7]

This removes that limitation. If the issue/pull request and project have different owners, then instead of directly creating a project item, we will instead create a "draft issue" which will be added to the board.

I don't believe this would be the right way to handle these cases, since draft issues aren't linked to their underlying content, so the actual issue/pr isn't linked directly.

I don't know, offhand, the origin of this limitation - but I think it's much more likely we'd want a holistic improvement to this in projects instead of attempting to workaround it in a non-intuitive way that might also be confusing.

Draft issues are also non-unique so this could potentially create multiple draft issues with the same content, for instance if a user applies a label, unapplies it, and then reapplies it 2 drafts for the same issue will have been created

[timrogers]

@mattcosta7 Thanks for taking the time to review this PR. That's really interesting! I wasn't aware of those limitations - I just saw that you could paste the URL of an external issue into a project board and the title (etc.) showed up, and I thought that would do the trick 😓

Would you be open to having this as some kind of advanced, optional case - perhaps configured with a boolean option which defaults to "off"? Being able to manage external issues using this workflow would be really valuable to me.

If it's a no (which I understand), then I'll fork this and create my own similar action which offers this functionality, but makes the trade-offs clear.

[mattcosta7]

@mattcosta7 Thanks for taking the time to review this PR. That's really interesting! I wasn't aware of those limitations - I just saw that you could paste the URL of an external issue into a project board and the title (etc.) showed up, and I thought that would do the trick 😓

Would you be open to having this as some kind of advanced, optional case - perhaps configured with a boolean option which defaults to "off"? Being able to manage external issues using this workflow would be really valuable to me.

If it's a no (which I understand), then I'll fork this and create my own similar action which offers this functionality, but makes the trade-offs clear.

We can take a look. urls do resolve when pasted - I'm not sure offhand whether the graphql api handles this, but if so, that makes sense, and wouldn't have the limitations I discussed!

[timrogers]

We can take a look. urls do resolve when pasted - I'm not sure offhand whether the graphql api handles this, but if so, that makes sense, and wouldn't have the limitations I discussed!

I have tested this out extensively, and the URLs do resolve if you use the "create draft issue" GraphQL mutation. You seem to get the exact same result as pasting a URL onto the board.

[timrogers]

@mattcosta7 Just to a reminder to take a look at this when you have a chance ❤️ Thank you so much!

[mattcosta7]

@mattcosta7 Just to a reminder to take a look at this when you have a chance ❤️ Thank you so much!

hey @timrogers sorry - had a really hectic week

I think we'll take this as is for now. We'll eventually remove this in favor of a more direct way to manage cross-org work, but for now unblocking this makes sense to me

Really appreciate the diligence here!

[mattcosta7]

https://github.com/actions/add-to-project/releases/tag/v0.3.0