Martin Pengelly-Phillips

Members
  • Content Count

    116
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by Martin Pengelly-Phillips

  1. We wrote a convenience method for this in our extension of the ftrack API. Might be something we can contribute via pull request.
  2. Yes it is possible. You can configure ftrack to not manage your files or copy them to new paths. Instead it can just use whatever path the files already have Typically this is known as an unmanaged location in ftrack terminology. The ftrack support team should be able to help guide you more in setting this up.
  3. We extended ftrack to automatically add fqdn and pid to the subscriber information when subscribing to events, along with an `EventHub.subscribers_for(event)` method. With those we can easily find any rogue event listeners and shut them down. Might be something for ftrack to add to the core?
  4. We've been waiting on this for a while now. Do you have an expected date of when this will happen?
  5. >>> for object_type in session.query("select id, name from ObjectType"): >>> print object_type["id"], object_type["name"] 4be63b64-5010-42fb-bf1f-428af9d638f0 Asset Build 01decdd1-51cb-11e3-9d5b-20c9d0831e59 Milestone bad911de-3bd6-47b9-8b46-3476e237cb36 Shot 11c137c0-ee7e-4f9c-91c5-8c77cec22b2c Task ...
  6. We also need to be able to manage managers for a project via the API. (Or have some other way to add folks to a project so that they get notifications without being assigned a task). This is critical for us as a larger studio.
  7. Support for querying JSON structure directly would be useful to us also. Right now we have some code using a 'like' query to match the parts of the encoded string (which is not great).
  8. Regarding the new release notes - how do you link to a specific version? Also, it was very useful to be able to link to ftrack glossary entries to ensure everyone was referring to the same definition of a term. Where is the equivalent functionality in the new docs? The new docs don't seem to be improving...
  9. Strike through would be great - it is useful also for indicating outdated information without having to actually delete the information.
  10. Now it seems like the release notes are no longer available in the old style docs either. Could you please bring back the olds docs as it seems the new docs are not getting updated with the required features.
  11. We've seen this too. Would be good to still be playable even when no thumbnail set.
  12. We find the 'old' documentation invaluable for sharing and training internally. The new docs simply aren't suitable (at least not yet). We miss the ability to: Link to specific sub-sections. Access the docs offline. Navigate left and right through a topic. Link to the specific release documentation (as we are often behind latest by a few versions). Link directly to API reference (via intersphinx) from our API reference and then maintain context in surrounding docs. Please bring back the 'old' docs or at least keep updating them alongside the new ones until you can support all these features in the new docs.
  13. We would definitely appreciate being able to hide lists in the left nav (maybe only be able to navigate to them from the list spreadsheet view). I'd almost see it as just an extension of the current 'open' flag on a List. If not open, hide in left nav.
  14. Yes, this would be great to have. Also, would be awesome if ftrack supported # completion for other entities in the system. E.g. Could start #mod and it would autocomplete to a modeling task.
  15. In addition, we currently link (via intersphinx references) to the ftrack documentation from our own internal documentation. Often this is to specific sections. How do we link to specific sections in the new documentation? Currently it only seems possible to link to whole articles.
  16. Not possible at present to do in one query. Are you wanting to do it in one query for performance reasons? The API does support batching calls under the hood, but it doesn't seem to be implemented for queries yet. There are some TODOS in the code though... def _query(self, expression): '''Execute *query* and return (records, metadata). Records will be a list of entities retrieved via the query and metadata a dictionary of accompanying information about the result set. ''' # TODO: Actually support batching several queries together. # TODO: Should batches have unique ids to match them up later. batch = [{ 'action': 'query', 'expression': expression }]
  17. Can you also improve the navigation for the new documentation - it's quite easy to get lost with lots of links and open tabs at present. Perhaps just adding Next, Previous buttons would help?
  18. We've been after this too - ideally there would be a 'last_accessed' timestamp on the user entity or something.
  19. Note that you could also write your own cache interface to connect to a shared cache if you want to reduce DB hits. For example, we run a Redis cache per site and created a RedisCache implementation as a subclass of ftrack_api.cache.Cache.
  20. Pretty sure we have reported this one in the past as well. It is very confusing behaviour currently!
  21. We are also surprised at the change to the documentation, especially as it also removes the versioned docs. Versioned docs are important to us as we may run several releases behind latest for stability and we can't have users constantly confused by references to features they don't have access to. Similarly, offline docs is nice to have. Finally, there seem to be no release notes in the new docs!
  22. > @Martin Pengelly-Phillips: I am interested how are you using the session. Are you creating a new session for each query / commit? No, we don't create a new session for each query or commit, as that would likely be redundant and slow. However, we often have a session (or two) in background threads in order to allow a main UI thread to continue unblocked. We also often run multiple sessions in background threads for event processing in order to avoid event deadlock.