Making modifications to plan shows new "Start" date on the UI?

Not sure if that’s an actual bug, but today I made a modification to a plan - I added a “C” race to it. Now in the UI, instead of showing the actual plan start date (Jan 27), it shows as if the plan had started today. (see photos attached). Is this an actual bug? Anyone experienced the same?


1 Like

I experienced the same thing last week.

1 Like

Hey there,

I don’t think this is a bug (and it shouldn’t affect anything in your plan negatively), but it does seem a little clunky/confusing. I’ll pass your feedback along to the rest of the TR team.

5 Likes

Yes. I modified a plan and it shows the date of the modification as the start date, but the remaining duration of the plan stayed the same. On the one hand, it makes sense as that’s the start of a “new” plan. On the other, it doesn’t show the original start of the plan. Kinda needs to show both somehow.

4 Likes

Keeping the start of the plan as is (original date) in the UI is my preferred solution, as it is nice to see how far you’ve gone. Additionally (but optionally), they can show “Plan change” when you make a change in the calendar.

8 Likes

FWIW: I just went to my Career page on the TR website and on the app the website shows my plan the original start date as Nov 15 and the app as Nov 11. (?) Both calendars show my plan starting on Jan 27, which is when I made the modification. So both are there if you know where to look. That said, the Career page shows the current definition of the plan, not the original definition.

Yes, conscious it does show the right dates on the career (see my print screen above), it’s just about being a bit confusing on the calendar. Not a Biggie, but any UI improvement is good right? :slight_smile:

2 Likes

I’ve had exactly the same thing happen this morning, I’d much rather the calendar show the actual start of the plan, maybe a notification could be added to a date when/if you modify a plan? That would allow you to look back at a plan and understand what you did and when.

2 Likes

I’ve experienced similar behaviour - adding and subsequently removing a “time-off” annotation was enough to trigger this: