This issue is labeled Project: DTS Service Delivery 2.0. but is not showing up on the Zenhub board filtered only to that label. My coworkers see the same thing.
I’m still trying to replicate this with other issues and will post back here with my findings. I wanted to share quickly in case it’s a known issue, as I’m in a time crunch that’s dependent on a functioning board.
I’m not sure how to edit this “topic”, but the title should be Label filters are not pulling particular issues onto the board
Hey Amenity,
Can you check to see if this happens in the web app as well as the extension? We don’t have any other reports of this. 
George
Sorry, I meant to specify that it’s happening in the Zenhub web app* as well:
(PS We’ve also been having issues with filter parameters/views not carrying across with hyperlinks for a while now, so these links may not render what’s shown in the screenshot.)
Hi Amenity,
Sorry to hear about the problem. I haven’t been able to reproduce it in my testing, could you double check a few things? (some of these are basic, just would help to have them confirmed)
I see there are 3 repos in the workspace, is atd-data-tech one of them?
atd-data-tech is the only repo we currently use for Zenhub. (I previously used atd-moped to connect PRs to issues, but no one else on my team uses that feature.)
If you filter the board by the labels “Service: Product” or “Project Index”, does the issue show up on the board?
No combination of should-work filters make the issues appear.
Are any other issues affected (missing on the filtered board) or just this one?
It appears this is happening to all of our “Project Index” issues. My other team members see it as well.
–
I wonder if it may have to do with the word Project being in the issues’ title, labels, or template comments—which are often left in issues:
Has the label been renamed lately?
No.
Has this issue moved from a different repo to atd-data-tech at any point?
Many years ago, we migrated issues from one repo to another. I can’t imagine any, definitely not all, of these issues existed at that time.
Very strange– the word “Project” in the label name shouldn’t have any special effect. The one thing that sticks out to me is issues having been migrated from one repo to another in the past. Maybe somehow Zenhub’s references to the labels in this workspace are still pointing to the old repo? I’ll ask internally and see if anyone has any other ideas
I am also having the same issue as Amenity (we’re in the same org).
@_af @George.from.Zenhub — any progress on this? It’s extremely disruptive to our work and reporting.
It is happening with issues and labels that did not exist when we used multiple repos. If there’s any other information I can provide so that you can reproduce, please let me know.
Hi Amenity, sorry we had hit a dead end but a colleague just thought of a reason this might be happening. It looks like that issue has an Issue Type that indicates it should be shown in the Planning Panel, not on the Board. The Issue Type isn’t synced to the GitHub repo’s types, which explains why you can’t see it on the issue sidebar on github.com, but it should be there if you view the issue in the Zenhub webapp.
Some followups to see if this is indeed the cause:
@_af Aha. I found it in the side panel. Removing the type fixed it, and it sounds like this one-time configuration should resolve the problem? Thank you.
And yes, the Issue Type field appears blank when using the Chrome extension:
Real talk: We’ve experienced continuous bugs using the GitHub extension, but this is a new level of discrepancy. If we’re reaching the point where functionally meaningful Zenhub data is invisible in GitHub, I’ll need to direct my team to use the Zenhub app exclusively. Correct?
@amenity - We can (and do) sync this data once the Issue Types have been configured in your GitHub organization. GitHub requires Org Admin rights to create these on the GitHub side (our app doesn’t have this level of access and we didn’t want to ask for it).
Here’s a quick video that you can send to your Org Admin and they can get it done in 30 seconds or so:
Thanks, George. Are these docs comprehensive and current, or do we have to watch the video to access the information and instructions?
Hey @amenity,
Docs are current, but don’t contain my helpful tip to work around the very slow syncs we’ve seen from GitHub. I’d suggest taking the 3 mins to watch the video…
Hope this helps,
George
