Chandler

Representing the scheduled events in a project as a CalDAV calendar is a feature we've always wanted with any project management software we use at my company. Presenting the events using the CalDAV protocol would allow all major calendar apps to view basic ftrack schedules which would go a long way towards replacing the need for a mobile app. This seems like a no-brainer to us in terms of propagating our studio's schedule out in the easiest to view way possible, so we will absolutely be developing this ourselves internally if ftrack doesn't get to it first. 😉 Our idea is basically to represent everything as read-only, which simplifies the needs. People don't need to edit from Outlook, they just need to see things. Using the calDAV Python library should go a long way to making this possible. The only design decision I still need to make is weather the calendars should be presented directly from the script itself, requiring open ports and a DNS address to point to wherever that script lives.... or, it could integrate with another calendar provider like Google Calendar, and simply sync the events to that service, making the calendars available for any users of that service instead.

I know this is old AF, but I had this need, and Lucas kindly informed me in the Slack channel that a 'is_latest_version' property will be available in Studio 4.4 That'll be a welcome addition.

TTT, if you have any kind of server or cloud instance of your own you can also run Actions as single always-running processes. These actions will be visible in the Web + Connect to all users without each person having to run the plugin via their launched Connect instance. As long as my action doesn't have a need to interact with local resources on that person's computer, I find this a much better way making Actions available for people. Thanks a lot for this boilerplate code guys - we are looking to implement the concept of a "generic" link that we can send to certain clients without it being personalized to their email address. This should get us there nicely.

I spoke to an ftrack rep at Adobe MAX this year who pretty much confirmed for me that this Mobile app is not a focus for the team, and in fact there's a high possibility that it won't be supported at some point in the future. This was very helpful to know, and for right now we've just decided to focus our workflow training around using the web tools directly, and integrating with the API. We haven't implemented time tracking into our overall workflow yet but it seems like it'd still be good for that!

Hey @Lorenzo Angeli could you clarify where the most up-to-date boilerplate code of your proxy solution is right now? I've seen you post it before, but I don't see a link in this thread, and this is all I can find now: http://docs.efestolab.uk/tools/proxy-location/index.html I'd like to explore implementing this on our end.

Sure. I have actually already created this in a way the way I want, but it would still be improved by a way of 'intercepting' a change rather than 'reverting' it as we have to now. I wrote a script that essentially determines the 'allowed statuses' for a Task or Milestone based on Incoming links. A Task/Milestone with any incoming links is first forced into a special status called "Locked". It is not allowed to be changed away from this status. If all of the incoming entities are marked as completed, then this changes from "Locked" to "Open". The script then finishes up by trickling down this configured status check to any outgoing links. This all works great, but there's a huge processing and usability problem with having to detect and revert these changes. As of right now, the user is told their status changes are all successful, and then they watch them slowly change to their allowed statuses where applicable. Sometimes these changes lag long enough that a full refresh is necessary. These status changes also persist in the history, which I may need to depend on for other logic later. This also rules out the ability for me to program any logic for when a Task first unlocks and obtains an "Open" status. So back to the regex thing - I imagine the same logic being used to deny a name change based on regex, could also apply to a status change and prevent that from happening. Just like a name change might be compared against the regex, the status name could simply be compared as well. What logic did you guys have in mind to actually set the regex for naming validation? Would it be stored within the entity itself and changed via the API or something? This would allow a script to dynamically change the approved regex's for a given field, which would be really sweet. Maybe even the field itself could support a 'validation' key with the regex directly in it??

Thanks for the quick fix on the docs, certainly clears up some confusion I had, haha. Regex would be very appreciated and powerful. I am also facing a need to validate statuses though, so I wonder if there's a way for a regex to apply to that field as well. It would be a little more abstract than than naming validation I guess, but I could see it still working. That may be out of scope though, if the discussion here is determined to be focused purely on validating text fields or something. The way that old validate function worked seems to be the right idea implementation-wise. I understand if the new API ruled out that type of event interception though. Overall the need seems to be having the chance to validate an event before it actually happens. That's the common thread with all of these issues - the fact that currently ANY validation needs to be the product of detecting a change and reverting it, as well as completely custom logic, is quite daunting and taking up a decent amount of my development time. I'm not familiar enough with the API yet to be thinking about performance, but I'm sure that would increase too when we aren't reverting so many changes.

I'm a bit confused as to the the ftrack.validate event subscription seems to remain in the documentation. I won't have a chance to test this for a while, but Project Code validation is a huge need for us, and the current docs seem to indicate this is possible...? https://help.ftrack.com/en/articles/1040479-events Scrolling to the bottom, I see the ftrack.validate topic listed. Are we saying if I set up an event listener for this topic I won't get anything?

I'd love an invite to this channel. Thanks in advance! chandlerphilly@gmail.com