Field Timer time should have type instant but the actual field type is dateTime
Answered
Hello! Question about
In Progress Work Timer requires setup
@jetbrains/youtrack-workflow-work-timer
Recently everything was OK and everything worked perfectly!
But then something happened and there was a mistake. Now I can not track the time.
The error is: http://prntscr.com/ix3oq7 . If i try manually change to http://prntscr.com/ix3pgc — the problem persists. I tried to create new project and add new worskflow — same issue =(((
I'm afraid to change anything, because I will lose all the data on the projects =(
Help me please
Please sign in to leave a comment.
Hello,
I can confirm this is a bug: https://youtrack.jetbrains.com/issue/JT-46421. Please feel free to add yourself to the watchers list of the issue to receive the updates.
Guys,
We have discussed this entire date-related problem once again inside the team. We expected this change to be a minor change and tried to workaround the related problems, but from the feedback, I see that it wasn't enough, and we lost some cases. We will implement the fixes for these issues in the nearest future.
@Mariya,
I understand that you want us to use the new workflow api in Javascript and we have already written some in the new api.
But there was a clear statement in the related issue: (https://youtrack.jetbrains.com/issue/JT-17984#comment=27-2116158)
"Thus, you can be sure old workflows will be supported for at least couple of years."
Based on this statement, we decided to write new rules in new system, and keep old rules untouched for now until we get used to the new api.
That lasted not even a year and we now have to decide whether we have our complete time tracking broken or we put some hours of work into fixing this issue now. Unfortunately we don't have the time now and have to enter the worktime manually...
>We changed the semantics of 'date' field [...] the value is set the midday of the corresponding date in UTC
Before that, the correct time was set even in a 'date' field and this is the only problem for our workflow...
If you tell users that old api is supported for a couple of years, you schould definitely not change that api after a few months :(
Hi,
There are 2 date-related types in YouTrack at the moment: 'date' (called 'instant' in API) and 'date and time' (called 'dateTime' in API). Since YouTrack 2018.1 release, 'In Progress Work Timer' and 'Stopwatch style Work Timer' workflows are not intended to work with 'date' type, only with the 'date and time' one. In most cases the transition was performed automatically, but if you have issues with 'Timer Time' field (an error like 'Field Timer time should have type instant but the actual field type is dateTime') please ensure the following:
Hello, Mariya!
Seems good, but one more question.
I have 2 projects with 2 similar settings.
I checked workflows, field types and time tracking settings, but only on 1 project everything is working:
1. I select "in progress", — "The timer is started."
2. Then select "To verify" and data in "Timer time" is updated.
everything is good
but on second project
1.I select "in progress", — "The timer is started."
2. Then select "To verify" and data in "Timer time" does not updated.
Looks like that time tracking is start, but do not stop.
Demo video: http://pw.ygseo.ru/youtrack-demo.mov
i have ~10 projects with similar settings, but only 1 project is working :(
I think, that yesterday, when i tried to fix it, I broke smth :(
It looks like the Timer time field is not updated at all (regardless the message).
Could you please show the texts of the rules which you have at the moment?
Sorry, i don't understand about rules. Maybe: http://prntscr.com/ixkja8 ?
Workflows:
Start: http://prntscr.com/ixkidy
Stop: http://prntscr.com/ixki5j
Fields -> timer time types: http://prntscr.com/ixkh4s
Time tracking: http://prntscr.com/ixkir2
also i clicked 'Restore' button on 'Workflows' list.
The rules look fine, the same rules work for me with the same configuration of Timer Time field.
Could you please check if the Timer Time field is really changed when you change the state in different projects to 'In Progress'? To be sure you need to change the state and then refresh the page. The history tab can also show if the field was changed.
Mariya, same issue.
On 1 project — fine, on other - bad =*(
History is update after I change state, but "Time Tracking" don't change. Looks like system can't cant write in Timer Time field and can't calculate spent time http://prntscr.com/iy0w79
I created new "test" project and there everything working. Old projects and new have same settings.
Video: http://pw.ygseo.ru/YoutrackVideoDemo2.mov
I can try to change everything that i see, but I can lose time tracking data(((
Hello! My research/observation about issue:
1. Create new project, setup time tracking there (create fields using auto workflow setup and etc.).
2. In this new project create new issue and set State "In progress" -> "To verify". Everything ok, "Spent time" calculates.
3. Go to project settings in Fields tab, and change "date and time" to "date" (it's incorrect settings now)
4. Check "in progress" -> "to verify". It doesn't work now. Same error as with all my projects.
5. Go back to project settings, and restore type to "date and time"
6. Check time tracking. It doesn't work , but i restore all settings.
--
(!!!) 7. If i delete fields "Spent time" and "Timer time", delete workflow, and then create them once more add workflow, and auto settings, then try to change state "in progress" -> "to verify", then everything will work.
Later, i'll try to do it for existing projects. I tested it, and looks like all data will be saved in time tracking....
I downloaded backup here: https://{aaa}.myjetbrains.com/youtrack/admin/databaseExport , but how can i restore it, if "something went wrong"?)
Thank you
@Mariya
We have the same problem, Timer is set to type "date", and we are using own workflows in the old system (non Javascript)
When I change the field type to "dateTime", the workflow shows "requires setup" and the error "Field Timer time should have type instant but the actual field type is dateTime"
Restore Workflow did not help and downloading workflows into the workflow editor show the error "Can't download custom fields schema. Unknown primitive type: dateTime"
So how is it possible to fix this so our old workflows still keep working?
Youtrack Build 40341 - 22 Mar 2018 - 22:00
Раман,
It looks like we have a problem with back and forth conversion of the date-related custom field type. We need to investigate it deeper, but it will take some time. As for now, if you need to restore the database from the backup, you'll need to write to our support and provide the backup, we'll restore the data.
You may track the progress of the investigation at https://youtrack.jetbrains.com/issue/JT-46517.
@Mariya,
I don't understang what's going on here now)
Now time tracking works well!
Friday evening — it doesn't work, Monday evening - everything good! :3 magic))
But there are new issue only in one project. When trying to change state from "in progress" or "to verify" to -> "Done" — error:
Workflow @jetbrains/youtrack-workflow-scrum reports error: TypeError: Cannot read property "_wrapped" from null (@jetbrains/youtrack-scripting-api/entities#279)
For me it's not important, but maybe it's bug...
Thank you for help!
@Thomas,
Unfortunately, I have to admit that your particular use-case is broken now. We have implemented several changes related to date custom fields, which lead to this:
1. We added a field of type 'date and time', which has time in presentation.
2. We changed the semantics of 'date' field - when you change it now, doesn't matter from UI, command dialog or workflow, the value is set the midday of the corresponding date in UTC: this is why your workflow doesn't work with 'date' field correctly.
3. We prohibited using 'date' instead of 'date and time' in workflows, and vice versa - therefore your workflow doesn't work if you change the type of your custom field, the workflow shows an error.
All these changes are supported in new workflow API (JS-based one), but not completely supported in deprecated API (and will never be).
Therefore, the most viable solution for you is to rewrite the time-related workflows to the new API (as the old API is not completely dropped yet, but it is not fully supported already). If you need any assistance please contact our support team, we will help you to migrate the rules. We are sorry for this inconsistency.
@Раман,
I suppose that in your case the restart of the server had the same effect as detaching and attaching the fields, so the workflows work as expected now.
As for the error you see now, it tells about the database inconsistency. In some rare cases the links between children and parents are broken (and the failing rule tries to close the parent when all children are done). Please consult this issue - https://youtrack.jetbrains.com/issue/JT-43006 - for the solution.
We have the same problem as Thomas. The only problem is setting value of dateType to UTC midday - so I start my work two hours before midday, finish it five minutes later and my workflow for TimeTracking shows that I spent "-1 hour 55 minutes" :)
I didn't notice this discussion thread until today, so I spent all yesterday solving this problem the same way as Raman did and with the same result - I rewrote all our workflows to JS, but changing type to dateTimeType is not enough - it doesn't work. Timer time is not set to Date.now(). And when set from past, it doesn't compute any Spent time and doesn't add new Work Item.
Will be any hotfix available? Or is it possible to downgrade to previous version of YT?
Great :)
Thank you :)
Hi Mariya, any news in this causa? Thx...
Unfortunately, the fixes are not implemented yet, but their implementation is scheduled for the next sprint.
And release date of "next sprint" is already known? We have all our WorkTimers based on this and now we are not able to use them at all.
So we consider downgrade to previous version (if possilbe ... ?) or we need that hotfix as soon as possible :-(
I can confirm that the fixes are now under development.
I can't provide any concrete estimation, but normally we release the bug fixes every 2-4 weeks.
That's strange - I installed april release and problem is solved. So latest release is OK for me.