A side question - is is:closed,merged necessary instead of just is:closed? Would there ever be a merged that isn't closed?

@archon810
closed will match pull requests that are closed without merging (as well as any closed issues), while merged explicitly refers to pull requests. is:closed, merged will give you the union of merged pull requests AND closed issues AND closed without merged pull requests. So it really depends on what you're trying to accomplish! In some cases, it doesn't matter (aka when you're already scoped to PRs) but it does matter if your workflow looks at issues AND PRs.

@2percentsilk we do have the same requirement, regarding iterations. As far as timezone concern, I think either two possibilities could be great:

• let users define a management timezone in the setting of the projects, which this workflow is based on
• run the workflow when the last timezone on the world has finished the iteration, there has to be a way to tell which is the latest timezone

maybe at least allow the modifier with a information about the issue until a perfect solution is found, i rather have the modifier with timezone issue, than not having it at all

@2percentsilk I'm not too concerned about the workflow running exactly when the iteration ends. As @alexanderniebuhr mentioned, an option would be nice but honestly in my mind the iteration isn't over until it's over for everyone.

Running it the day after the iteration ends would be fine, or when the last timezone hits and the day is officially over. IDLW, UTC−12:00 is the "last" time zone and is ~8hrs behind NYC.

Apologies for reviving this older feature request, but I found myself wanting this exact same thing.

Regarding the timezone issue, the only idea I can come up with is adding a particular timezone field to the project in the project settings and giving users the option to view the project as a different timezone than the one configured

I would also like to see status supported in the auto-archiving feature.

+1

I can now report that this is broken. It archived all our things across all "status" fields - so it executed part of the filter and ignored the thing it deemed invalid. This is bad @2percentsilk

Thanks for the report and sorry this happened :(

The filter shouldn't run at all if a piece is invalid so I'll get that filed and fixed.

While we don't have an undo button, if you go to the archive page, you'll be able to select your items and restore them to the project board with their custom field values they had previously.

Thank you!

is:closed, reason:"not planned" should do that for you!

Thank you so much! I just tested this out and it works perfectly.

Apologies for the noise on a (somewhat) unrelated discussion thread!

It would be good indeed. In my case, this would help archive only "Done" tickets, not all closed tickets. Is there any info on when this would be available? Thanks! 😄

This feature would indeed be useful since we cannot prevent PR to close issues: https://github.com/orgs/community/discussions/66741

Once PR are merged, this workflow archives the issues after a few days, even though the status is still in QA and not even in production yet.

@goslackware - This (along with auto-add workflow) will be available in GHES 3.9 👍

This looks to be the same as https://github.com/orgs/community/discussions/36466#discussioncomment-3922308

It appears different to me. The filter appears as valid:

last-updated is only used inside Projects so we added support for updated to make it more consistent with the rest of GH search. We encourage users to use updated. I will let the team know that the doc needs to be updated. Thanks for reporting this!

Oh seems like this is the correct query to use: is:draft,pr is:closed -is:merged.