Remus Avram

  • Content Count

  • Joined

  • Days Won


Posts posted by Remus Avram

  1. Hi all,

    how can I assign a user to a project via ftrack_api?

    I tried with:

                           {"context": project,
                            "resource": user,
                            "type": "assignment"

    but I get the following error:

    Server reported error: ValidationError(Appointment of type "assignment" cannot be created for "user" and "show")


    But if I get an existing appointment of a project and inspect the data:

    (Pdb) for k in allocation.keys():print k, ': ', allocation[k]
    resource :  <User(55095a4c-4839-11e6-a626-005056a745dd)>
    resource_id :  55095a4c-4839-11e6-a626-005056a745dd
    context_id :  28d104b6-8be5-11e7-a763-005056a745de
    context :  <Project(28d104b6-8be5-11e7-a763-005056a745de)>
    type :  allocation
    id :  0b60299c-a469-11e7-aa6e-005056a745de

    the context is a project and the resource is a user.


  2. Hi all,

    we would like to give production the ability to manage the roles of the user without accessing the Ftrack System settings.

    From our perspective, one way to do it is to add in the right-click menu a sub-menu "Roles" like the "Managers" one.

    Or adding the roles to the user from the user Profile.

    Or to emit an event when a manager type is added to a user. In this way we can match the "Managers" types with the "Roles" types and do it through an action.  ( @Luigi already started a discussion abut this here 

    Thanks for your support!

  3. 38 minutes ago, pawel said:

    if I query an entity again and it was previously retrieved and is already cached it will be returned from the cache, won't it? 

    If you are using session.get() yes, but if you are using session.query() it will query the DB again.

    41 minutes ago, pawel said:

     Otherwise what is actually cached if every query fetches new data anyway?

    I think the cache makes sens in some cases, for example if only one generic user is allowed to change some data. But in most of the cases you want to query the DB again before changing it to be sure that nobody already updated it.

    44 minutes ago, pawel said:

    Currently I have a session per call but it is troublesome to make sure all sessions are closed properly.

    I think the open/close session is not the main problem of having a session per call. 

    Having a session per call it will slow down the process.

  4. Hi @pawel

    we are using one session as a global session.


    #1 in case of the option one how is the cache invalidated?

    why do you want to invalidate the cache? Normally you don't need to do it.

    If the session is running for a long time, when you want commit a change, first you query the ftrack entity again and then you commit, just to be sure that the entity didn't change in the meantime. 



  5. On 4/8/2017 at 7:55 PM, Mattias Lagergren said:

    You only have the id and no information at all about the type of entity? There is no real good solution for that I'm afraid. Testing/Guessing is of course possible, but for performance reasons I would recommend that you try to keep identity of the entity and the entity type together.

    Keeping the id and the type of the entity together works for us pretty nice. 

    But in the event hub, the event['data']['selection'] contains the id and the 'context_type' of the entity instead of the type of the entity. In this case we can't get nice the entity.