instinct-vfx

not a server change. The error message tells it as it is. Python2.7 support will be dropped in arrow. Arrow is a dependency of the ftrack api. The ftrack api also supports python3. You will either have to live with using older versions of arrow or update to python3.

Congratulations and looking forward to what will come out of this!

Thanks for the heads up (and sorry for the delay in replying, email notifications seem to be off, have to check). This is VERY welcome!

Heya, i was wondering if there are any plans already to make the python api both 2.x and 3.x compatible? We are using the api in some of our server applications and would like to move towards python 3. Cheers, Thorsten

I would love to get some experiences on this! We are looking into it. So far we based our plans mostly around what the mill showed but i am eager to hear other shops' thoughts!

Hm. I actually wish for both. You can still track and they do show up. I would like to be able to STOP people from logging time on tasks they are not assigned to nor is the task still beeing worked on. (If you favourite tasks, then they stay there forever). Cheers, Thorsten

Oh, and stopping should also be done when locking the machine. The way our old local agent handled idle time (that is both "machine got locked" and "machine is idle") was that after a certain grace period (i think 10min back then) logging back in would trigger a dialog asking you what you want to do with the time since idle. Was it really on the task that was running or was it time off (forgot to stop when going for lunch) or on a different task (forgot to stop/switch) when going into a meeting). That seemed to work pretty well. Cheers, Thorsten

I agree with connect integration though i am unsure if this is maybe too shop-dependent to be generally implemented. e.g. i would need this rather configurable and user selectable at different leves (e.g. opening max in 3 different shot contexts does not necessarily mean i need to track to the last one only. Might be opened for reference etc.)

+1 for a limited (in terms of ACL permission controllable) way to change timelogs Here are a few from the hip (just saw your concepts, have not yet gone over those!) Validate/Sanity check time logs (no more 24+h days) Beeing able to lock timelogs after a certain amount of time has passed (e.g. lock editing and adding timelogs older than a set date or older than x days) Prevent logging time to arbitrary tasks (only allow adding timelogs for tasks a user is or was assigned to) Allow for notifications (with lots of over- or undertime) More to come and good to see that on the roadmap!

I'd hang in there if it was available! Cheers, Thorsten