Andrew Lawrence

Hi @finnjaegger apologies for the delayed follow-up here. We totally understand your frustration here, ideally our integrations frameworks would be able to be customised by anyone regardless of development skills. It's certainly a direction we're trying to move in, making the integrations much more seamless to setup without needing to dive into code (for example our recent release of the plugin manager), but we've still got a long way to go. As of today, depending on what you need to do with connect you may need to dive into some of its configurations to get the fully value out of it. That said, our support team is more than happy to try and walk you through things. If you prefer to drop us an email at support@ftrack.com we'll do our best to point you in the right direction. Cheers, Andrew

Hi @Frank Rueter, thanks for the update there. You're absolutely right, it shouldn't be too difficult to implement separate configs for different sites, however it isn't something that we've had request all too often. We know there are studios out there who use multiple ftrack sites, or even remote artists or freelancers who may connect to different sites at once and have the option to easily switch between those would be great. We'll make sure to get this logged on our end with the product team. Thanks for the excellent suggestions here. Cheers, Andrew

Hi @John T, thanks for writing in here. While this isn't possible today, we are working on an upcoming feature that will address part of this issue. The feature we are working on (which we're calling split tasks) will allow you to break up a single block of time over time over non-consecutive days. So for example you bid 4 days for a shot, but 2 of those days happen this week and the final 2 happen next week. Therefore the total is still 4 days total, even though on your gantt you can see it happened over a 2 week period. You'll be able to break this down by whatever unit you schedule by (days or hours). In this first iteration we don't take into account the concept of having an artist assigned to a task with a certain %, though its an interesting consideration for future iterations. While split tasks is something we're still actively working on I'd love to get your thoughts on if it might help you with some of your use-cases in the short term? Looking forward to hearing any thoughts of feedback you might have. Cheers, Andrew

Hi @Frank Rueter, thanks for the excellent suggestion here. Being a keyboard evangelist myself I'm always down for more ways to speed up workflows with keys. We were testing this out and although not a keyboard shortcut per say, if you hold down CMD (on a mac) or CTRL (on windows) and click on the objects dropdown arrow, that will expand everything beneath that object in the hierarchy. The same goes in reverse if you want to close it, whereas a normal click will only drop down what is directly below it. I'm sure you may already be aware of that and realise it doesn't cover all cases, but just wanted to post it here incase We'd be happy to log the remaining shortcuts as a feature request with our team though, thanks for providing such detailed use-cases there, it really helps our team when designing these things to know how users intend to use them. Cheers, Andrew

Following up with a post here for the community as our team have been working with @JTosto to solve this issue on a support ticket. As mentioned, there was a recent update rolled out to fix an update in the SG integration (details on that here), however this authentication error was to do with the legacy 2FA authentication in ShotGrid (before moving to the Autodesk ID system) For anyone experiencing errors like this, If you have 2FA enabled for legacy logins you need to setup the google authenticator to the generate codes for your legacy login. This is completely separate from the Autodesk ID, since you cannot use the same codes as you would for your Autodesk ID. Thanks Jordan for bearing with us there while we got this sorted. If anyone is still experiencing similar issues don't hesitate to contact support@ftrack.com and we'll get thins looked into for you. Cheers, Andrew

Hi @itot Thanks for writing in, we'll be happy to help out here. May I confirm, are you referring to the shared views which can be shared with select users? (as shown below) If so then yes, you can either remove a user from that selected view by clicking on the cross next to their user, or you can use the *remove view* option to remove it altogether If you have any further questions don't hesitate to give us a shout. Cheers, Andrew

Hi @matthieu & @Frank Rueter Great to see you both here, we've sent you both invites to the Slack Group. See you there! 👋

Hi Houssam, Thanks so much for the additional context here, I've gone ahead and scoped out a request for this with out product team for consideration. While I can't confirm any ETA, don't hesitate to reach out here should this get more urgent for you and your team. Cheers, Andrew

Hi @altarak In this instance A would be correct. For a single select attribute the limitation has no affect at all. For a multi-select attribute it has an affect and limits to 50 selected entities. The above statement covers everything that this limit does.It does not: * Limit how many entities you can select from (Cam1 - Cam55 can be selected from) * It does not limit how many times Cam1 can be used by Shots. I.e. you can have 1,000,000 shots all using Cam1. (Unfortunately the Sidebar info tab on Cam1 will not handle this very well as it will try to display that it has been used by 1,000,000 shots – a known limitation) I realise the concept here could be far better documented on our end to understand the ins and outs here. We'll definitely take note to try and make this a bit clearer both in docs and in-app. If you have any further questions don't hesitate to give us a shout. Cheers, Andrew

Hi there everyone, Andrew from the ftrack support team here. We realise this is an incredibly important request for a lot of studios and given how long it's been around, we hate that we haven't gotten to this sooner. I wanted to provide a transparent update where we are currently at with this request. I realise this started out more as an undo request for annotations (which is now possible), but has since morphed into a request for the ability to undo deletions across the board. Like most of you, we're totally with you that it can be a frustrating experience when someone accidentally deletes something only to find theres no way to revive it. The thing that's been holding us back up until now is unfortunately some technicalities with how we store data on the backend. There's a trade-off we have to consider of allowing someone to delete the data (which keeps the database optimal and running performant) or putting checks in place to recover deleted data, but at the risk of the database becoming bloated). One of the ways we've discussed that could potentially avoid this is to have a concept of a trash can that will auto-empty after a certain period of time (a.k.a 1 week). This way we almost solve the best of both problems, whereby we allow users the flexibility to recover an item once its deleted, but only within that set timeframe (which keeps the database from getting bloated) We'd love to hear from our community, do you think that this approach might be suitable? Our thinking here is that people will only really want to recover something soon after they've deleted it, or do you think a timeframe like that would need to be longer? Would love to hear any thoughts or feedback you have. Cheers, Andrew

Hi @Houssam Thanks for bearing with me there, I can confirm that the Dependency Type and Lag are not currently accessible via the ftrack API. We'll be sure to scope out a feature request for this addition, though we'd love to learn a bit more about your specific use-case to ensure we're scoping something out that would suit your need. If theres any background you can share on the types of workflow you envision for this we'll be happy to get something written up for consideration. Cheers, Andrew

Hi @Divine Mercy Thanks for reporting this and apologies for the delayed response here. We've been discussing this with the team and this isn't something that is currently possible in ftrack today. We've been discussing alternatives as to what an implementation of this might look like, and your suggestion of allowing you append to the version name still be recognise as the same parent in ftrack seems like a good approach. We've gone ahead and scoped out a feature request for our product team here to keep you informed. We'd love to hear from others in the community if they also hit this issue regularly and what other use-cases we could capture to help us scope this out. If you have any further questions don't hesitate to give us a shout. Cheers, Andrew

Hi @Alex Gumbleton, Thanks for reporting this and apologies for the delayed response here. You're absolutely right that the workflow for tracking timecode isn't ideal in ftrack today. Most studios we talk to tend to use a string as you outlined, however this loses out on functionality such as calculations, and using the projects fps to calculate timecode. While I've gone ahead and scope out a request for this with our team, I'd love to understand a bit more how you'd like this to work. Internally, our thinking would be, create an attribute type for timecode, this would inherit the fps of the project to accurately reflect and calculate timecode value. We'd love to hear if you, or anyone else in the community feel this would be a good path to take, or if theres anything else we are overlooking here? Cheers, Andrew

Hi @Mani Varma Our sincere apologies for the delayed response here, we realise we totally dropped the ball on this one but would love to get you sorted. May I ask if you are still having this issue, and if so please drop an email to support@ftrack.com as we may need to look into your specific workspace. Thanks for bearing with us in the meantime here. Cheers, Andrew

Hi @altarak Thanks for the update there, you bring up a good point that we don't explicitly call out in our docs the limit of 50 entities per link. We'll take note to make this clearer in our docs. I should note that as custom attribute links is a relatively new feature, we're continuing to iterate on this and looking into the implications of removing this limit. It's definitely something we want to work towards and are currently investigating a way to ensure it is performant with a larger number of links. Please give me a shout if you have any further questions on this. Cheers, Andrew

Hi @Divine Mercy Thanks so much for reporting this, I agree this would be a great feature to have. I'd love to learn a bit more about your ideal implementation, for example: * Would 10 seconds be enough for your preferred jump time, or would you ideally like a preference to set that jump time * Do you have a preference on which shortcuts might be most familiar to you (ones that line up with other apps that you use?) And just for clarification, I'm guessing you'd want this across all areas in ftrack where reviewing is possible right? (internal, client review etc?) I'd love to learn more so we can scope out a fully fledged feature request with our team. Cheers, Andrew

Hi Alain, Thanks so much for the detailed explanation there on your ideal workflow. I really love the idea of allowing someone to type a user readable value but then have it displayed to them how the system will capture it. I've gone ahead and scoped this out internally with our product team. If anyone else on this thread has additional use-cases they'd like us to include please let me know and I'll ensure we get this all capture. Really appreciate the engagement here, thanks for helping us make ftrack better! Cheers, Andrew

Hi Folks, Thanks for the updates here, the ability to clone/duplicate a workflow schema was added to the workflow section of System settings in the 4.5 release of ftrack (released mid 2020). There is no officially supported/recommended way to change an existing project's workflow schema yet. That said, you can still change the schema on a project via the API if you understand the risks and know what you are doing. Essentially it is all about ensuring that all status types, task types, and other references on the project itself to the workflow schema will still be supported by the new workflow schema. If you understand these risks and have access to a sandbox project, testing there first would be recommended. Cheers, Andrew

Hi @Liam Our sincere apologies for the delayed response to this. The team have been hard at work getting ready for the next release of cineSync Play and we've got some exciting things in store. Access to our API is definitely something that we've got planned for cineSync Play and are keen to release it as soon as it's available. That said, it won't be something that will be available right out of the gate for our public release, but as soon as we're able to provide a better timeline on this we'll do our best to keep you and the community here updated. I totally appreciate that doesn't provide an ideal answer for you as of today, but just to let you know it's absolutely a core part of our plans for cineSync Play. If we can help clarify anything in the meantime don't hesitate to reach out. Cheers, Andrew

Hi Folks, Thanks for keeping this thread alive, I just wanted to provide an update where we stand with this. Data validation upon entry in the UI is something that continues to be a priority for studios and we totally see the benefit here. Having this enforced at the UI level will absolutely help reduce the need for additional scripts, validation, checks and overall just provide a better experience for the end user. Currently, we haven't managed to find an elegant implementation for this that provides a smooth user experience. While a regex implementation definitely seems do-able, we're looking at ways that we can make this more accessible to everyone. While that means it isn't something we are working on currently, it continues to be something we are thinking about and as we're researching the next iterations of ftrack studio it's absolutely something we are continuing to think about. I appreciate that doesn't provide a great solution for today, especially given that this has been highly requested for a long time now. As many of you have pointed out and from what we've seen, studios currently work around this limitation by using actions, where custom validation can be enforced. However with our goal being to make ftrack as easy to setup as possible, we realise maintaining those actions (especially for studios who may not have the technical resources) is far from an ideal solution. Theres a lot of great use-cases here (mostly around validation on shot / asset / project data), but we'd love to hear of any others that are important to your studio. We'll continue to track these internally and will share more news with you when we have news on how this implementation could shake out. Thanks for bearing with us here. Cheers Andrew

Hi Folks, Thanks for keeping this thread active, I just wanted to provide an update where we stand with this implementation. We're currently in early investigation as to what it might take to provide the decimal point as a setting to the user. We've seen some great examples of usage here (fps being the most common ones) but if theres any other specific ones that are important to your studio we'd love to hear them. We really appreciate you bearing with us here, we realise it's been in our backlog for a long time for what seems like a relatively simple feature so we really appreciate everyone bearing with us here. While we're not quite at the stage where we can give any estimate on when this might land, we definitely encourage folks to keep an eye on our public roadmap as we aim to add things there as we begin working on them. Thanks for all the amazing insights and suggestions here, don't hesitate to reach out if anyone would like to discuss such an implementation further, and we'll be sure to keep you posted. Cheers, Andrew

Hi @Mani Varma thats great news! Thanks for sharing that with the community, happy to see you found a solution to this. If you have any further questions don't hesitate to give us a shout. Cheers, Andrew

Hi Folks, Thanks for the follow-up on this thread. Just for visibility for the community, when you delete projects or items in the ftrack UI (for a cloud hosted site) the storage allowance should be correctly reflected in the ftrack UI. We've definitely seen the odd instance here and there where this hasn't happened though, and if anyone here is still seeing that please drop a message to support@ftrack.com with your site URL and our team will look into it and get you sorted. Hope that helps to clarify here. Cheers, Andrew

Hi @matthew_h_k, Thanks for reporting this and our sincere apologies for the delayed reply here. When deleting products within ftrack the storage *should* but reflected right away with the new changes. If that isn't happening it's possible there may be something specific happening on your site. If that is the case, would you be able to drop us a mail to support@ftrack.com with your specific ftrack workspace URL and our team will dive in to this right away. Cheers, Andrew

Hi @Houssam Apologies for the delayed response here, but thanks for the great question! You can edit set these links through the ftrack API. There are two types of entities that can be linked: * Versions can be linked to other asset versions, where the link entity type is AssetVersionLink. * Objects like Task, Shot or Folder, where the link entity type is TypedContextLink. Both AssetVersion and TypedContext objects have the same relations incoming_links and outgoing_links. To list the incoming links to a Shot we can use the relationship incoming_links: for link in shot['incoming_links']: print(link['from'], link['to']) In the above example link[‘to’] is the shot and link[‘from’] could be an asset build or something else that is linked to the shot. There is an equivalent outgoing_links that can be used to access outgoing links on an object. To create a new link between objects or asset versions create a new TypedContextLink or AssetVersionLink entity with the from and to properties set. In this example we will link two asset versions: session.create('AssetVersionLink', { 'from': from_asset_version, 'to': to_asset_version }) session.commit() So in your case, for tasks you would use the TypedContextLink. We have some more examples on this here Hope this helps clarify, if you have any further questions don't hesitate to give us a shout. Cheers, Andrew