Patrick Boucher ftrack

Hi Jasper, Those settings, "Users can claim tasks" and "Enable multiple task claim", refer to the capacity of a user being able to see a task and assign themselves to it. This doesn't change the underlying fact that tasks in ftrack have always been assignable to more than one person. Disabling "Enable multiple task claim" will however make it impossible for an unprivileged user to assign themselves to a task if someone is already assigned to it. Someone with full edit capabilities on the task could still assign it to multiple people though. Cheers, Patrick

Fernando, Do you have a link to the particular piece of documentation? I'd like to review it with the team and adjust the wording to make things clearer if necessary. Thanks!

Hi Fernando, I've not been able to reproduce your issue. Things are working as expected with the process outlined below. Here is the state of my task before: Then I edited it with the following code (taken from an interactive Python session): In [40]: task = session.get("Task", "f6d48138-1e81-11ed-abfe-c2a412b9415f") In [41]: task["bid"] = 5 * 8 * 60 * 60 In [42]: session.commit() In [43]: And the result was as follows: You'll notice that the number input in the bid field is an integer representing the number of seconds. This is computed using 8 hours per day because that's what my "Workday length" is set to in my Scheduling settings. If this is not the behaviour you're seeing, could you provide us with a full set of steps so that maybe we have better luck at reproducing the issue? Cheers, Patrick

Hi @John T, As far as I know, this is not possible. Tasks can arbitrarily be under any number of types of objects. They don't need to be under a shot. As such, maybe we could show the name of the parent of the task but that may not always be relevant. What I would suggest as a workaround would be to include the name of the shot in your task name if you want to include it here. For example, task `comp` could be `001_comp` for the first shot. I'll file a feature request on your behalf with our product team. They can probably come up with something more eloquent than the above workaround. Cheers, Patrick

Hi @thechiclayano, This is an interesting problem because, unfortunately, I'm not seeing the same behaviour as you are. First off, I'm assuming that between each session you'd make sure that the task with the name `create_test_task` didn't exist under shot `create_test_shot` prior to your trying to create it. I think this is a safe assumption because otherwise, you should get an `IntegrityError`, not a `ValueError`. Given that assumption, I tried reproducing your code against my site via an ipython session, and this is what I got: In [4]: ftrack_api.__version__ Out[4]: '2.3.3' In [5]: session = ftrack_api.Session() In [6]: shot = session.query("Shot where name is create_test_shot_02").one() In [7]: task = session.create("Task", {"name": "create_test_task"}) In [8]: shot["children"].append(task) In [9]: session.commit() In [10]: task = session.create("Task", {"name": "create_test_task_02"}) In [11]: task["parent"] = shot In [12]: session.commit() No errors. Then I figured, maybe it was because you were doing it in multiple independent sessions so I quit ipython, started it back up again, and tried the last portion of the example code, changing the task name as to avoid the `IntegrityError`: In [4]: ftrack_api.__version__ Out[4]: '2.3.3' In [5]: session = ftrack_api.Session() In [6]: shot = session.query("Shot where name is create_test_shot_02").one() In [7]: task = session.create("Task", {"name": "create_test_task_03"}) In [8]: task["parent"] = shot In [9]: session.commit() Again, no errors. When I focused on the quoted error message: Server reported error: ValueError(Cannot set relationship to string value.) I noticed that your last change to the task was setting the `type` attribute to the value `'animation'`. This won't work and will indeed cause the above error. I can easily reproduce this: In [16]: task["type"] = "animation" In [17]: session.commit() Server reported error: ValueError(Cannot set relationship to string value.) NoneType: None What's happening is that a task's type is an actual object. You can query `Type` objects in ftrack like any other object type. For example: In [25]: task = session.query("Task where name is create_test_task_03").one() In [26]: task["type"] Out[26]: <dynamic ftrack Type object 4625836160> In [27]: task["type"]["name"] Out[27]: 'Texture' In [28]: animation_type = session.query("Type where name is Animation").one() In [29]: task["type"] = animation_type In [30]: session.commit() So what this all boils down to is that the error you put in your message is legit but points to the small mistake in setting the task type in the last example but I can't reproduce the problem with the first example you say doesn't work. If this is still a problem for you, could you provide the error you get for the first problematic example? Cheers, Patrick

Hi Kristin, I suspect this has to do with the fact that the Worked days column is actually computed from multiple time log entries connected to each particular task, but I can definitely pass this along to our product team as a feature suggestion. Thank you! Patrick

Hi Brad, I've reached out to colleagues regarding #1. I'll chime in as soon as I know more. Regarding #2, having a dev or staging server is part of our Enterprise offering. Enterprise doesn't necessarily mean on-prem/local install. Those two are distinct. We also have clients without a dev server that build capabilities into their toolsets such that some environments can only read/write to specific projects. This method isn't as neat a separation as separate servers, but with Global API keys constrained to particular projects, making sure tools in development can only access a single project via a constrained key has a low barrier to entry. Cheers, Patrick

Hi Houssam, Currently, having two objects with the same name and same parent is impossible. In your use case, our recommended workaround would be to temporarily rename one of the tasks which seems to be what you're already doing. Cheers, Patrick

Hi Brad, As you've figured out, you currently need to specify an active user. I understand the point you're making and will certainly bring it up with the product team on your behalf. As you point out, there are a number of avenues for improvement. Cheers, Patrick

Thanks for the update. I'll have a chat with Lorenzo and one of us will get back to you.

Done, @RaphaelFuzari.

Hi Aivaras You could use an Enumerator custom attribute. Give the attribute a label of `Timer is on` and make its possible values `Yes` and `No`. Then you'll need to write an event listener with our Python API. You'll have to listen to `Timer` creation and deletion events. When a `Timer` is created, you can use the `user` and `context` attributes on the timer to set the `Timer is on` value to `Yes` on the correct task. When the timer is removed, you can set the value to `No`. Obviously the above requires some Python programming experience. Cheers, Patrick

Hi John, Can you try with the release version of Connect that can be found here? Cheers, Patrick

Hi Jason, Here is documentation on Actions in ftrack. These are Python scripts that use our API to interact with ftrack. If this Action were running on a server with access to the location where you want to create the folders, it should be easy for someone with development experience to implement one. We have a repository of example actions that can help someone get up and running faster by copying the basic structure of a pre-existing action: https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/ Currently, using the API is your quickest route to implementing folder creation in your pipeline. Cheers, Patrick

Hi Cody, The user interface doesn't have any affordances to reconnect a version from one place in your dataset to another after upload. This can be achieved through the API though, if you want to go that route.

Hi Raphael, I'm happy to see you were able to get the result you wanted by hacking things for yourself. This, obviously, isn't supported yet but I'll log a feature request with our product team to always have the left panel collapsible. Thanks for suggesting this.

Hi Evan, You should be able to use the following code: record = session.get("Context", some_id) The resulting object in the variable will be an instance of a dynamically created type that represents your object. Ideally you'd know the type when querying which could avoid some calls depending on your actual case.

Invite sent, @JKarimaa. Welcome!

Hi Alan, Are we talking about a tree widget where you expand portions and drill down to leaves? If you don't know or have a sense of the scale of the project, it might be a costly operation to load everything initially. A past strategy I've used is to load the top node and its children first. Then I'd start one or multiple threads to load children based on a priority that makes sense (top node displayed on screen first, if a node is expanded, prioritize the children in that node, etc...). This would basically preload items quickly enough that the user wouldn't get much latency when navigating the tree. Of course, this comes at the expense of more API requests with each being lighter than a full request. If you do want to do it in as few calls as possible, you could do the following or similar: items = session.query( f"select name, object_type.name from TypedContext where parent_id = {prj_id} or ancestors any (parent_id = {prj_id})" ).all() This would imply 2 calls. One for the project itself, but you might already have a handle on that, and one for the objects under it. This will give you unordered data that you can then put in a tree. Cheers, Patrick

Hi Mani, If the user was disabled (uncheck the "Enabled" checkbox for their record via "System Settings -> Users and Groups") they can be reenabled if licenses are available. If the user was deleted, unfortunately, they can not be restored.

Hi @Liam, Which object was your dynamic enumerator custom attribute added to? If you add a dynamic enumerator to a `Project` you should get the following data in `event['data']`: { 'groupers': [], 'attributeName': 'dynamic_enum_01', 'recordData': { 'changes': {}, 'entity': { 'entityId': '02a4f54a-f17a-11ec-b799-e2c3e97de4aa_9', 'entityType': 'show'} }, 'filters': [ { 'disabled': True, 'property': 'name', 'initialConfig': { 'disabled': True, 'property': 'name', 'root': 'data', 'id': 'ft-dynamicenumerator-2000512-query-filter' }, 'root': 'data', 'id': 'ft-dynamicenumerator-2000512-query-filter' } ], 'sorters': [] } Notice that the `entityType` value is `show`. You can use the `split()` trick shared by @Mattias Lagergren to get your `id` and then do a `session.get('Project', <id>)`.

Hi Frank, This is definitely not an unreasonable feature request. I've gone ahead and submitted this to our product team on your behalf! Cheers, Patrick

Hi Fernando, To create the actual Type object (which is what you're looking at in this list) you can start with this: t = session.create('Type', {'name':'foo'}) session.commit() This will create a type that will not be linked to any workflow schema. To view the attributes you can specify, you can use our in app API Reference that you can find under Help in the user menu (your user icon in the top right of the UI). Next, to tie this new Type object to a schema you can do as follows (I'm using the VFX schema as an example): project_schema = session.query("Project where name = 'VFX'").first() task_type_schema = project_schema["task_type_schema"] task_type_schema["types"].append(t) session.commit() So the API model is as follows: A ProjectSchema has a TaskTypeSchema A TaskTypeSchema has one or many Types The Type is what shows up in the Workflow -> Types page of the System Settings. I hope this helps! Cheers, Patrick

✅ 🥳

Unfortunately you can only view notes linked to AssetVersions by either: A ) Showing the notes attribute of your choice in the Version spreadsheet B ) From the task spreadsheet, showing a specific task or shot in the side panel and viewing them in the notes tab We will bring up your use case with the product team and submit this as a feature request.