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

Move the issue from specific column only #41

Open
altafard opened this issue May 22, 2020 · 4 comments
Open

Move the issue from specific column only #41

altafard opened this issue May 22, 2020 · 4 comments

Comments

@altafard
Copy link

Hi, @alex-page! What do you think about it?
In my case I have a column 'To pull' with unassigned issues. And I want to move issue to column 'In progress' on assigning. After closing issue in column 'In progress' it must appear in 'Done'. But sometimes people assign themselves on closed issues and this issues turn back to the column 'In progress'.

Is it good idea to add new argument 'from column' and move issue only if it is in this column right now?

@alex-page
Copy link
Owner

alex-page commented Jul 15, 2020

Hey @altafard this is a great idea. Would you be interested in making a pull request? Happy to give more direction.

@BobbyRBruce
Copy link

I too would benefit from this feature. In my case when a PR is created it's added to a column called "New". Things in "New" should stay there until I've had a chance to look at them. We effectively triage new PRs, add labels, ensure the correct people are assigned, etc, then we move them to another column manually. My use of this Action is so if a PR is updated it's moved to the column "Updated" automatically. Unfortunately, if someone creates a PR, then immediately updates it (fairly common), it's moved from "New" to "Updated". I want to stop this.

Something like this would be great for me:

jobs:
    move-to-updated:
        name: "Move to Updated"
        runs-on: ubuntu-latest
        steps:
            - uses: alex-page/github-project-automation-plus@v0.8.3
              with:
                project: "PR Status Board"
                column: "Updated"
                exclude-in-columns: ["New"]
                repo-token: ${{ secrets.GITHUB_TOKEN }}

In the meantime is there a workaround? I'm trying to find the right if to stop the job being run if the PR is in the column "New" but it alludes me.

@BobbyRBruce
Copy link

I too would benefit from this feature. In my case when a PR is created it's added to a column called "New". Things in "New" should stay there until I've had a chance to look at them. We effectively triage new PRs, add labels, ensure the correct people are assigned, etc, then we move them to another column manually. My use of this Action is so if a PR is updated it's moved to the column "Updated" automatically. Unfortunately, if someone creates a PR, then immediately updates it (fairly common), it's moved from "New" to "Updated". I want to stop this.

Something like this would be great for me:

jobs:
    move-to-updated:
        name: "Move to Updated"
        runs-on: ubuntu-latest
        steps:
            - uses: alex-page/github-project-automation-plus@v0.8.3
              with:
                project: "PR Status Board"
                column: "Updated"
                exclude-in-columns: ["New"]
                repo-token: ${{ secrets.GITHUB_TOKEN }}

In the meantime is there a workaround? I'm trying to find the right if to stop the job being run if the PR is in the column "New" but it alludes me.

I realize my exact issue a little bit the flip of this thread, as in i want to move from anything but specific columns, but I think it has similar, overlapping ideas at play.

BobbyRBruce added a commit to BobbyRBruce/github-project-automation-plus that referenced this issue Aug 23, 2023
This adds the `column-allow-list` and `column-deny-list` optional
inputs. If neither is set the behavior of the action is identical to
before.

`column-allow-list` may be set to a string or list of strings
(separated by comma or newline character) which specifes columns that
the action may move cards from only. That is, if `column-deny-list` is
set to `todo,wip` then only cards in `todo` and `wip` can be moved by
the job. If unset all cards in all columns may be moved (assuming
`column-deny-list` is also unset).

 `column-deny-list` may also be set to a string or list of strings
(again, separated by a comma or newline character) which specifies
columns that the action may never move cards. That is, if
`column-deny-list` is set to `todo,wip` then cards in `todo` and `wip`
will not be moved by the job. If unset all the cards in all the columns
may be moved (assuming `column-allow-list` is also unset).
from.

This addresses:
alex-page#41.

Tests have been added to verify previous behavior is preserved and
these new inputs function as intended.
BobbyRBruce added a commit to BobbyRBruce/github-project-automation-plus that referenced this issue Aug 23, 2023
This adds the `column-allow-list` and `column-deny-list` optional
inputs. If neither is set the behavior of the action is identical to
before.

`column-allow-list` may be set to a string or list of strings
(separated by comma or newline character) which specifes columns that
the action may move cards from only. That is, if `column-deny-list` is
set to `todo,wip` then only cards in `todo` and `wip` can be moved by
the job. If unset all cards in all columns may be moved (assuming
`column-deny-list` is also unset).

 `column-deny-list` may also be set to a string or list of strings
(again, separated by a comma or newline character) which specifies
columns that the action may never move cards. That is, if
`column-deny-list` is set to `todo,wip` then cards in `todo` and `wip`
will not be moved by the job. If unset all the cards in all the columns
may be moved (assuming `column-allow-list` is also unset).
from.

This addresses:
alex-page#41.

Tests have been added to verify previous behavior is preserved and
these new inputs function as intended.
@BobbyRBruce
Copy link

I've been wanting to better understand how Actions work, so took the opportunity to act on my suggestion and create a PR (#88) to address the issue outlined here.

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

No branches or pull requests

3 participants