This is the second time in beta I’ve seen this happen, have emailed support. My waiting perspective now displays no actions. Filtering the sidebar to ‘On Hold’, and the actions by ‘Remaining’, no actions appear. It’s treating the ‘Remaining’ filter the same as ‘Available’ for this purpose. Meaning the only way to see actions in an ‘On Hold’ context, and only those actions is to select ‘All’ in ‘Filter by availability’, which also shows completed items. Any users seeing the same?
I had this happen some time ago and I completely forgot about it. I assumed I did something wrong and never revisited the issue. (thank you for bringing it up! and filing the bug)
If it helps: I have two contexts on Hold, one of those two is nested; both of them have two actions items each (no due or defer dates for any). I have 8 projects on hold. I created a new perspective, copied your settings as posted in the first screenshot.
The results make no sense for me. Not only do I have no matching actions (like you), I have actions that do show up that have nothing to do with on hold projects or contexts.
- No Context: shows a single action item that has nothing to do with on hold projects or contexts.
- Context On Hold 1: No actions
- Context On Hold 2: No actions
PLOT TWIST: If you go back to the perspective window > change filter by availability to Available > the view will refresh after a second > change the filter by availability back to remaining > the view will refresh after a second > The results are what I want.
- Context On Hold 1: 2 correct actions
- Context On Hold 2: 2 correct actions
You already submitted the bug, so I’m sure they’ll get on it. It looks to me like a refresh issue in the initial view when electing On Hold vs. other options. My other perspectives have not had an issue with refreshing details that I have noticed anyway.
Edit: I closed the perspective, sync’d, quit the application, opened OF2, opened the perspective and the view is correct. That might be why more people are not noticing it. If they make an adjustment, thinking they might have made a mistake, after the refresh of the view, they might not think twice.
Yes, it happened in a previous build and then the bug was either explicitly fixed or corrected itself. Unfortunately the latest build as of this post still has it broken, but we can keep this thread active when it is resolved, and if/when the recursion appears again.
The bug is resolved as of build 207657. Will update title.
Thanks for keeping tabs on this!