Leaderboard


Popular Content

Showing most liked content since 03/25/2018 in all areas

  1. 1 point
    The issue with update events on hierarchical custom attributes should be fixed in an upcoming maintenance release (scheduled for 3.5.25)
  2. 1 point
    Hi Tim, Sorry for the confusion on this - you're correct, the id is wrong when accessed from the sidebar. To work around this you can do the following: if '_' in entityId realId, junk = entityId.split('_') As for the entityType - this is old style entity type from the backend. Instead of using 'task' you would want to use 'TypedContext' on the session: session.get('TypedContext', realId)
  3. 1 point
    Mattias Lagergren

    ftrack Browser tabs

    Hey Erik, this is something that we're considering for the future. It could very useful if you have a lot of tabs open for different projects.
  4. 1 point
    Hi and welcome to the forum. The Collection object that you get can be accessed much like a list: for note_component in some_note['note_components']: ... some_note['note_components'][0] et.c
  5. 1 point
    Hi, Sorry for the delayed response on this. I don't see a reason why changes to `TypedContextLink` shouldn't emit update events. I have added a bug task to look into this. Thanks for the feedback. Regards, Lucas
  6. 1 point
    We have asked for this also. It is essential to be able to track every change, especially in case bad data enters the system. With a proper audit model we would have a chance of getting back to a good state without losing data through a restore from older backup. Note that even the API does not provide sufficient granularity at present and still uses old data types making it harder to relate to actual data. We are also interested in there being a facility for giving the reason for a change - e.g. why the status was changed. A sort of special linked note / metadata attached to the change event.