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.
(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.)
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?
If you filter the board by the labels “Service: Product” or “Project Index”, does the issue show up on the board?
Are any other issues affected (missing on the filtered board) or just this one?
Has the label been renamed lately?
Has this issue moved from a different repo to atd-data-tech at any point?
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 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
@_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:
Can you see the issue when the board has no filters applied? (I would think not)
Can you see the issue if you search for it in the Goals & Planning Panel (sidebar on the left of the board)?
@_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:
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…