Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable add-to-project to add issues to a specific status / column in the project #71

Open
stuart-leitch opened this issue Apr 12, 2022 · 17 comments · Fixed by #282
Open

Comments

@stuart-leitch
Copy link

Thanks so much for this action, it's a great help with making sure that new issues land on my team's board for visibility.

It would be great if we could also specify the status (board column) that the issue should be added to. For example, we have an 'Inbox' column where new issues go for triage.

@kalgurn
Copy link

kalgurn commented May 14, 2022

Hi @stuart-leitch, it's doesn't seems like the API method AddProjectNextItem supports such kind of functionality https://docs.github.com/en/graphql/reference/input-objects#addprojectnextiteminput

As a workaround I can suggest to use a custom action for this particular use case.
I've made one derived from the add-to-project action, feel free to fork/use/contribute

@mattcosta7
Copy link
Contributor

Thanks so much for this action, it's a great help with making sure that new issues land on my team's board for visibility.

It would be great if we could also specify the status (board column) that the issue should be added to. For example, we have an 'Inbox' column where new issues go for triage.

@stuart-leitch sorry for the late reply here - would the Item added to project workflow help that use case, without needing to handle it from the action

Screen.Recording.2022-05-18.at.3.02.56.PM.mov

Agreed that supporting more granular scenarios here might be helpful for some usecases, but for adding a default value to incoming items in a non-granular way, that should be a good step

@OliverRC
Copy link

OliverRC commented Jun 10, 2022

For custom columns it looks like you could possibly update the item after it is added to the project:
https://docs.github.com/en/issues/trying-out-the-new-projects-experience/using-the-api-to-manage-projects#updating-a-custom-text-number-or-date-field
https://docs.github.com/en/issues/trying-out-the-new-projects-experience/using-the-api-to-manage-projects#updating-a-single-select-field

I managed to reproduce the desired behavior using GraphQL:

# https://docs.github.com/en/issues/trying-out-the-new-projects-experience/automating-projects
# https://docs.github.com/en/issues/trying-out-the-new-projects-experience/using-the-api-to-manage-projects#finding-the-node-id-of-a-user-project
- name: Get project data
  env:
      GITHUB_TOKEN: ${{ secrets.ORG_PAT }}
      ORGANIZATION: my-org
      PROJECT_NUMBER: 4
  run: |
      gh api graphql -f query='
        query($org: String!, $number: Int!) {
          organization(login: $org){
            projectNext(number: $number) {
              id
              fields(first:20) {
                nodes {
                  id
                  name
                  settings
                }
              }
            }
          }
        }' -f org=$ORGANIZATION -F number=$PROJECT_NUMBER > project_data.json

      echo 'PROJECT_ID='$(jq '.data.organization.projectNext.id' project_data.json) >> $GITHUB_ENV
      echo 'COMPONENT_FIELD_ID='$(jq '.data.organization.projectNext.fields.nodes[] | select(.name== "Component") | .id' project_data.json) >> $GITHUB_ENV
      echo 'PRIORITY_FIELD_ID='$(jq '.data.organization.projectNext.fields.nodes[] | select(.name== "Priority") | .id' project_data.json) >> $GITHUB_ENV
      
      echo 'BACKENDPORTAL_OPTION_ID='$(jq '.data.organization.projectNext.fields.nodes[] | select(.name== "Component") |.settings | fromjson.options[] | select(.name=="Backend") |.id' project_data.json) >> $GITHUB_ENV
      echo 'PULLREQUEST_OPTION_ID='$(jq '.data.organization.projectNext.fields.nodes[] | select(.name== "Priority") |.settings | fromjson.options[] | select(.name=="High") |.id' project_data.json) >> $GITHUB_ENV

- name: Add Issue to project
  env:
    GITHUB_TOKEN: ${{ secrets.ORG_PAT }}
    ISSUE_ID: ${{ github.event.issue.node_id }}
  run: |
    item_id="$( gh api graphql -f query='
      mutation($project:ID!, $issueid:ID!) {
        addProjectNextItem(input: {projectId: $project, contentId: $issueid}) {
          projectNextItem {
            id
          }
        }
      }' -f project=$PROJECT_ID -f issueid=$ISSUE_ID --jq '.data.addProjectNextItem.projectNextItem.id')"

    echo 'ITEM_ID='$item_id >> $GITHUB_ENV        

- name: Set fields
  env:
    GITHUB_TOKEN: ${{ secrets.ORG_PAT }}
  run: |
    gh api graphql -f query='
      mutation (
        $project: ID!
        $item: ID!
        $component_field: ID!
        $component_value: String!
      ) {
        set_component: updateProjectNextItemField(input: {
          projectId: $project
          itemId: $item
          fieldId: $component_field
          value: $component_value
        }) {
          projectNextItem {
            id
            }
        }
      }' -f project=$PROJECT_ID -f item=$ITEM_ID -f component_field=$COMPONENT_FIELD_ID -f component_value=${{ env.BACKENDPORTAL_OPTION_ID }} --silent

@dtzar
Copy link

dtzar commented Jun 20, 2022

The workflow option is nice, but I still believe there would be value added by having an option to configure this from the GitHub action because:

  1. There are a number of use cases where you would want specific tags to be added only when done via the action - versus all new issues added to the project.
  2. Currently, GitHub workflow on beta projects doesn't allow any customization of the "Item added to project" workflow. You can only add the status label with one of the pre-defined values there.

@ezio-melotti
Copy link

It would really be useful if there was a way to set custom fields, and even more useful if this could be done conditionally depending on what label triggered the action (and/or possibly other factors).


For example, I have a project to track release/deferred blockers, with the default status field and a custom type field. When an issue is labeled as either release-blocker or deferred-blocker, I want to:

  • unconditionally set the status field to be set to todo
  • conditionally set the type field to either Release blocker or Deferred blocker.

I also want the type to be updated if the issue is re-labeled (e.g. a deferred-blocker that becomes a release-blocker). This could be implemented with something like:

name: Update GH projects

on:
  issues:
    types:
      - labeled

jobs:
  add-to-project:
    name: Add to the Release and Deferred Blocker project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/add-to-project@v0.1.0
        with:
          project-url: https://github.com/orgs/python/projects/2
          github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
          labeled: release-blocker, deferred-blocker
          label-operator: OR
          # set project fields (syntax is made up to illustrate the idea)
          set-field:
            # unconditionally set the `status` field to `todo`
            status: todo
          set-field:
            # if the issue was labeled `release-blocker`, set the `type` field too
            if: github.action.event.label == "release-blocker"
            type: Release blocker
          set-field:
            # if the issue was labeled `deferred-blocker`, set the `type` field too
            if: github.action.event.label == "deferred-blocker"
            type: Deferred blocker

This will unconditionally set the status field on the project to todo, and conditionally set the type field to Release blocker or Deferred blocker depending on the label that triggered the labeled event.


If there was only an unconditionally way to set custom fields, the same result could be achieved by creating a separate step for each label, e.g.:

          # (set-field syntax is made up to illustrate the idea)
          labeled: release-blocker
          set-field:
            status: todo
            type: release-blocker
          ...
          labeled: deferred-blocker
          set-field:
            status: todo
            type: deferred-blocker

If you prefer, I can create a separate issue about conditional addition, assuming a way to set (custom) fields is going to be added to the action.

@Hafnernuss
Copy link

Hi @stuart-leitch, it's doesn't seems like the API method AddProjectNextItem supports such kind of functionality https://docs.github.com/en/graphql/reference/input-objects#addprojectnextiteminput

As a workaround I can suggest to use a custom action for this particular use case. I've made one derived from the add-to-project action, feel free to fork/use/contribute

Unfortunately, this does not seem to work (anymore?), and this is also a feature I would find highly useful for the already stated reasons.
We would like to sort new issues according to their labels (bug, feature request) into seperate columns in our project board.

@jeherve
Copy link

jeherve commented Aug 18, 2022

Unfortunately, this does not seem to work (anymore?)

The examples above use the [ProjectNext](https://docs.github.com/en/graphql/reference/objects#projectnext) object, which can only be used with the old "Classic" GitHub projects, while this action is now compatible with the new GitHub Projects. You'll consequently want to use the new ProjectV2 object and mutations instead.

For our particular needs in this issue, we'd need:

@ishowta
Copy link

ishowta commented Nov 3, 2022

There are Github Actions to solve exactly this problem, and I used them. 🙏
https://github.com/titoportas/update-project-fields

@dgwyer
Copy link

dgwyer commented Dec 6, 2022

For anyone else that needs to add an issue to a custom default column in a project (i.e. other than 'Todo'), you can do this directly via the project UI. You don't need to add anything else to your YAML workflow file to get this to work.

I used the Add To GitHub Projects action to assign newly opened issues to the project. And then in the project UI simply specified which column to use as the default!

@bradtaniguchi
Copy link

I used the Add To GitHub Projects action to assign newly opened issues to the project. And then in the project UI simply specified which column to use as the default!

I honestly forgot the workflows tab existed! Last I checked it was still under construction and thus disabled. Glad to see it can handle the use-case without much fussing around. 😄

@dgwyer
Copy link

dgwyer commented Dec 7, 2022

I honestly forgot the workflows tab existed! Last I checked it was still under construction and thus disabled. Glad to see it can handle the use-case without much fussing around. 😄

Yes, it would be super useful if this info was added to the GitHub action readme docs!

@mattcosta7
Copy link
Contributor

I honestly forgot the workflows tab existed! Last I checked it was still under construction and thus disabled. Glad to see it can handle the use-case without much fussing around. 😄

Yes, it would be super useful if this info was added to the GitHub action readme docs!

Happy to accept PRs for it!

@ezio-melotti
Copy link

Unless I'm missing something, the solution suggested in #282 doesn't solve the issue.

The "Item added to project" workflow only works for the default "Status" column, and the documentation linked in the PR doesn't explain how to use a different column:
image

Currently it's still not possible to:

  • set the value for a column that is not "Status"
  • set the value when an issue is updated, rather than just added
  • set multiple values (e.g. Status and Type)
  • set values conditionally (e.g. set the Type based on a label)

(See #71 (comment) above for more context.)

In addition, if this is handled from the project workflow instead of the action, each individual project would need to be updated manually.

I would recommend to:

  • update the documentation to explain how to set a different column (if at all possible)
  • reopen this issue to track and implement the features listed above

@mattcosta7 mattcosta7 reopened this Dec 14, 2022
@mattcosta7
Copy link
Contributor

Sorry, closed this by merging the docs update, but meant to reopen for future improvements. thanks for calling it out

@Snailedlt
Copy link

Snailedlt commented Aug 5, 2023

@mattcosta7 Seems like @OliverRC's solution solves the issue of adding to a specific column. If it does, then it could be added to this action.

I'm thinking something like this could be added:

name: Add issues to project columns based on issue events

on:
  issues:
    types:
      - opened

jobs:
  add-to-project:
    name: Add issues to project
    runs-on: ubuntu-latest
    steps:
      - name: Add new issues to project column 'Todo'
        uses: actions/add-to-project@v0.5.0
        if: github.event.action == 'opened'
        with:
          project-url: https://github.com/orgs/<orgName>/projects/<projectNumber>
          github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
          column-name: Todo

      - name: Move assigned issues to 'In Progress' column in project
        uses: actions/add-to-project@v0.5.0
        if: github.event.action == 'assigned'
        with:
          project-url: https://github.com/orgs/<orgName>/projects/<projectNumber>
          github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
          column-name: Done

      - name: Move closed issues to 'Done' column in project
        uses: actions/add-to-project@v0.5.0
        if: github.event.action == 'closed'
        with:
          project-url: https://github.com/orgs/<orgName>/projects/<projectNumber>
          github-token: ${{ secrets.ADD_TO_PROJECT_PAT }}
          column-name: Done

If column-name has a value we run @OliverRC's script after the issue has been added to the project.

Or maybe we want a totally new action called something like move_to_column_in_project to isolate the two?

@janiswehen
Copy link

janiswehen commented Sep 27, 2023

I have successfully implemented a solution using GitHub Actions! 🎉 I utilized the project-field action to set project fields based on different conditions.

Here's an example of how I set it up:

I created a Workflow that modifies the project field PR Status to Develop if a PR is in Draft and changes it to Ready for Review if the PR status alters to a normal one.

name: Update PR in Project
on:
  pull_request:
    types: [opened, reopened, ready_for_review, converted_to_draft]

jobs:
  project-draft-pr:
    if: ${{ github.event.pull_request.draft == true }}
    name: Update Project Item Draft PR
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: EndBug/project-fields@v1
        with:
          fields: Review Status
          github_token: ${{ secrets.GHPROJECT_SECRET }}
          project_url: https://github.com/users/my-user/projects/project-number
          resource_url: https://github.com/my-user/repo/pull/${{ github.event.pull_request.number }}
          values: Develop
  project-pr-ready:
    if: ${{ github.event.pull_request.draft == false }}
    name: Update Project Item PR Ready for Review
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: EndBug/project-fields@v1
        with:
          fields: Review Status
          github_token: ${{ secrets.GHPROJECT_SECRET }}
          project_url: https://github.com/users/my-user/projects/project-number
          resource_url: https://github.com/my-user/repo/pull/${{ github.event.pull_request.number }}
          values: Ready for Review

To adapt this to your setup, you'll need to modify the project_url and resource_url to match your project and repository. Also, ensure to create access tokens in your account settings and set a secret GHPROJECT_SECRET in the repository settings to your token.

This approach assumes that PRs are automatically added to your Project. You can configure this in the Workflow settings of your Project or by integrate the following action between - uses: actions/checkout@v3 and - uses: EndBug/project-fields@v1:

     - uses: actions/add-to-project@v0.3.0
        with:
          project-url: https://github.com/users/user-name/projects/project-number
          github-token: ${{ secrets.GHPROJECT_SECRET }}
        id: add-project

This will ensure the issue is added to the project as needed. Looking forward to hearing if this solution is helpful for others as well!

@janiswehen
Copy link

There are Github Actions to solve exactly this problem, and I used them. 🙏 https://github.com/titoportas/update-project-fields

This one works for the beta projects. You can use https://github.com/marketplace/actions/update-github-project-fields for the new ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.