Patrick Boucher ftrack

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

Just for completeness' sake, an ftrack engineer chimed in on the subject, and I'm leaving a link here as a reference:
https://github.com/ftrackhq/ftrack-javascript/issues/73

Hey Patrick,
Sorry for the late response. I ended up doing exactly that and just filtering the events in the callback. I for the life of me cannot find the documentation where '<' and '>' operators can be used for filtering so maybe it was some old information or I am just going insane. Either way, I believe we are doing it the intended way in the callback now.
Thank you!

Hey Patrick, 
 
Thanks you are right!! I got confused by the two types of user_security_roles haha it works now
 

Thanks! seeing the attribute configuration route was helpful and as our list of custom attributes expands that should help pull select values.
We've decided to restructure the tool to better match ftrack's structure so information can be pulled more dynamically as you've mentioned. It's an extra query but faster than pulling everything we might not need.

I've updated this in our docs and they should be deployed when the API is next tagged and released.

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 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 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 guys,
Can I get an invite?😇
raphael.fuzari@o2pos.com.br
Thanks 🙏.

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.

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 can you add lucas@animotions.be please, thank you!

hi, can you add tuananh.phan@gmail.com? thank you!

Hi I also would like an invit please, arthur.villiers@gmail.com
thx!

Found it in one of the documentation and it worked. I was trying to subscribe to ftrack.widget.update before which didn't work out as expected.
https://help.ftrack.com/en/articles/1040449-custom-widgets
window.addEventListener('message', function (event) { var content = event.data; console.debug('Got ' + content.topic + ' event.', content); if (content.topic === 'ftrack.widget.load') { //Store credentials for later. window.credentials = content.data.credentials; } else if (content.topic === 'ftrack.widget.update') { // Load new data. } }, false);