Jump to content

instinct-vfx

Members
  • Content Count

    60
  • Joined

  • Last visited

  • Days Won

    7

instinct-vfx last won the day on October 3 2017

instinct-vfx had the most liked content!

About instinct-vfx

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

876 profile views
  1. not a server change. The error message tells it as it is. Python2.7 support will be dropped in arrow. Arrow is a dependency of the ftrack api. The ftrack api also supports python3. You will either have to live with using older versions of arrow or update to python3.
  2. If this is an on-prem installation you need to trust your internal SSL certs (e.g. by using CA_BUNDLE environment variable). If this is hosted by ftrack you should contact support about it.
  3. Thanks for the heads up (and sorry for the delay in replying, email notifications seem to be off, have to check). This is VERY welcome!
  4. Does this change lead to "way more" being supported but still limited? Or will this completely remove the limit?
  5. This is a front-end limitation, you can assign and unassign more through the API. We worked around it by managing tasks that need more than the supported user count in the UI in a separate local tool. It can seemingly be worked around also by changing a MariaDB setting. You may want to talk to support directly if you want to go down that route (we felt that managing that many users from the current legacy resource selector is not exactly fun anyways).
  6. Agreeing with this. Another thing broken in the new docs is that line breaks in code sections seem to be broken. e.g. https://help.ftrack.com/administering-ftrack/on-prem/configuring-the-database Generally i found the old format to be more accessible to browse. And having the section headers (like "Managing a local installation" on the same level as its contents seems pretty confusing) Cheers, Thorsten
  7. You are trying to create an assignment where i think you should be creating an allocation, no?
  8. Heya, i was wondering if there are any plans already to make the python api both 2.x and 3.x compatible? We are using the api in some of our server applications and would like to move towards python 3. Cheers, Thorsten
  9. Hey there, not sure without actual queries/code, but i think this is the same limitation that i have hit. The reason is, that context is a dynamic (or polymorphic) entity that may be different entity types. Hence it does not contain all the attributes that an actual instance may or may not have. If this is what you are seeing then this was addressed in 3.3.35: NEW APIDeveloperAdded support for complex queries with projections and criteria containg attributes from concrete subclasses. See also: http://ftrack.rtd.ftrack.com/en/latest/developing/api/query_syn
  10. I'd like to add my vote here. The db is ever growing. We have not even really started publishing assets and versions in our main business lines and the db is getting pretty clunky already.
  11. Hey there, there was talk about docs. For now you can use the attributes and .keys properties/methods. Here is a snippet that prints a map of the available types and properties: import ftrack_api session = ftrack_api.Session( server_url='FTRACK_URL', api_key='API_KEY', api_user='USER' ) ftypes = session.types for ftype in sorted(ftypes): print ftype for attribute in sorted(ftypes[ftype].attributes.keys()): print "\t" + attribute Cheers, Thorsten
  12. Seems the repository is still private, or is it just me?
  13. I would love to get some experiences on this! We are looking into it. So far we based our plans mostly around what the mill showed but i am eager to hear other shops' thoughts!
×
×
  • Create New...