Postpone A&P task bug - Undo Postpone unavailable

Question

I just reported this bug, but this is urgent. Do we get prioritization points for posting about it here too? Many months ago I had previously reported the problem that we need to be able to Postpone tasks multiple times. I see that was also a question a few weeks ago here…
[Link Removed]

I hope that we can prioritize fixes for both these issues. We need to be able to postpone a task to a later stage more than once without needing to select Undo Postpone. That is really awkward to undo a postponement so that it goes back to a stage that is already completed. It really feels like a “workaround” solution.

But furthermore, there is not always this Undo Postpone workaround solution available. The Undo Postpone only exists in some circumstances. I’m not totally sure when it exists and when it doesn’t. But I currently have 50+ issues for Out of Date Verses stuck in Stage 3 in multiple languages when we’ve already done the work of Stage 4. This task was previously postponed to Stage 3, but there’s no Undo Postpone option. Of course, we also can’t track our progress in Stage 4 because this task is still hanging us up in Stage 3. We could just complete that task, but it’s a lot, and now is not the time to double check that recurring issue again.

Please prioritize these issues soon! Thank you!

Answer 1

One quick way to deal with an unwanted (temporarily) check is to go to the Project Plan and move it to a later stage.

Comments

Thanks anon848905. That can certainly help me when I’m in a bind. Of course, it is still a very awkward workaround. Moving that task in the Progress Plan only moves it for one project at a time (we are working in 10), and it moves it for all books, even the book that other team members are working in Stage 1 where we want that task to appear there. But at least I can move it temporarily as you suggested while I’m wanting to edit the progress of a later Stage, and then move it back before I do a send/receive so that it will still be in its proper place for the other users.

---

Okay, I tried that temporary workaround, and it works, in a clunky sort of way. Here are the steps I followed…

1. Open Progress Plan and change the Stage at which the check in question is first checked ( changed it from Stage 1 to Stage 2).
2. Open A&P and find the task still in Stage 2 but now with the Postpone option available (it worked!)
3. Postpone the task to Stage 4.
4. Go back to Progress Plan and change the Stage for this check to first appear back to Stage 1 (this is necessary because teammates are working on other books at the same time, and I don’t want my next send/receive to change this setting for them working in other books)
5. Go back to Progress Plan and look for the check and see that it’s no longer in Stage 4. Hmmm, maybe it moved back to Stage 1? No. Where was it? In Stage 3. It looks like my postponement from Stage 2 to 4 was a relative move, IOW it moved it two stages later, so that when I changed the plan back to having it in Stage 1, it also moved the current location of the check to Stage 3 (still two stages later than the Stage it’s set to first appear in).

Anyway, this is a workaround solution, and it works. Hopefully, all tasks and checks (yes, both) will be able to be postponed to later stages repeatedly in the near future.

---

Ben+Pehrson - just to be clear. What happens when you change the stage back to Stage 1 is that Paratext looks at the current stage and identifies that you are currently working in Stage 3 (having already marked the tasks of Stage 1 and 2 complete). Therefore, since you are now working in Stage 3 and you have issues with the check it shows up there.

You would see the same behavior if you had in fact corrected all of the errors in Stage 1 and then moved forward to another stage. If then when you were in Stage 3, someone introduced an error that is verified by that check, the check would show up in the current stage (3).

Paratext doesn’t take you back to the stage where the check was originally listed. It shows that check in the stage you are working.

Hope that is clear.

Blessings,
anon848905

Answer 2

Thanks anon848905, yes, I agree that that’s how the program works, and that almost reflects the situation I was describing, except that Stage 2 was the latest stage that was still incomplete, not Stage 3. So the check that I had previously postponed by 2 stages (when it was previously assigned to Stage 2) – and for which I also subsequently moved the Stage at which it first appears in the Project Plan back to Stage 1 – now appeared in Stage 3, showing me that the postponement action is not absolute but relative to the Progress Plan, even retroactively to any previous postponements after the Progress Plan is changed. I only looked for the check possibly appearing in Stage 1 because I had assumed I would have seen it still postponed to Stage 4, but when it wasn’t there, I wondered if there was a bug in the program that might have made it appear in a Stage we had already finished. But there was no bug. Instead, when I found it in Stage 3, I realized that the postponement action is actually relative to whatever the current Progress Plan is, even retroactively.

I’m sure this is a lot more detail than most anyone wants to know – and too full of run-on sentences – but what I’m describing does suggest a fair WARNING about even temporarily moving checks around in the global progress plan. Doing so will not only apply to the position of the check from this point on, but it will also adjust any previously assigned postponements to a position relative to the new position of the check. So I think the big take-away is to make sure this workaround is only followed TEMPORARILY, and that the movement of the check in the plan be moved back preferably before one does their next send/receive and this change goes out to all the users on the team. Furthermore, if a team ever decides to move a check in their Progress Plan permanently, be aware that this will effect the stage at which any previous postponements appear. It’s probably not a big deal. Teams will just deal with the checks at whatever stage they appear, but it may seem a bit counter-intuitive.

I’m really glad to know that this work-around exists, but I think the clunky nature of it (and the widespread need to use it from what I have experienced and heard) speaks to the urgency of the need for the Paratext developers to adjust the limitation on postponing tasks only once.