Lorenzo Angeli

Hi @Finn Jäger, what i would try to is to upload the file as you like , but ensuring ftrack does not re encode it. This can be done though connect, overriding the encode event listener: or straight from the api hope it helps. L.

Hi @marc mantei glad to you hear you sorted it If there's anything else, please do not hesitate to get back in touch! L.

@jen_at_floyd you should have an email.

Hi @marc mantei , please ensure you are extending the FTRACK_CONNECT_PLUGIN_PATH and not overwriting it. L.

Hi @zhouyu08512, as the question seems a bit vague, would you mind sending an email to support@ftrack.com , providing all the information you have about the tool you want to write and what you've been trying so far (with code if possible), so we can try to help ? Looking forward to hear more from you! L.

Hi @Aaron Powell, more than "whatever works for you" is really the fact we try not to enforce these , as are usually defined by studio structures and pipelines. that said, it really depends on what you are after..... overall if you just have scripts which use the ftrack_python_api, my suggestion would be to have them stored in a central place and mapped to the PYTHONPATH (you can think also to have some inheriting from a central path for utilities and having modules named for each show with the specific code you need.) On how, you can go from setting PYTHONPATH into the envs to use something like REZ to handle it all from there. The latter option could be a bit of a stretch , depending on how often you need to maintain these, but might worth the time. Hope it helps. L

@ch_brown @Florent Dupont you should be having an invitation email now, let us know if does not work for any reason. Cheers. L.

Hi @John, sorry for the delay on getting back to you. if you have a centralised storage scenario, the easier one would be to provide your own custom location , having it registered and then through an action provide the transfer of the components into the other location. The only thing you need to be careful about are the priorities of the location themselves, so you don't (by mistake) make the other one replacing (as priority) the centralised storage. here couple of examples might be of help in your journey https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/multi_site_location/ https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/migrate_components/ I'd suggest looking into these while keeping at hand the documentation for the location/structure system. http://ftrack-python-api.rtd.ftrack.com/en/stable/locations/tutorial.html?highlight=location https://help.ftrack.com/en/articles/1040442-locations Hope it helps. L.

Hi @zhouyu08512, sorry for the delay on getting back to you. Versioning is handled by ftrack itself and is not something we allow to define though the Nuke Studio templated names. I'd suggest, if you haven't yet, trying the latest version available on the forum and see whether the video issue is solved. let us know how it goes. If the problem persist, please open a ticket with support@ftrack.com so we can properly investigate your issue. Cheers. L.

@Mani Varma would you mind opening a ticket with support@ftrack.com providing the logs from ftrack-connect and any relevant information about your setup, so we can properly have a look into your issue ? Thanks. L.

Hi @Bryan Fordney if you are using actions and events (hence you are in python land), I'd suggest using the appdirs module. We use the same to store connect and other plugin credentials, here an example. Hope it helps. L.

Hi @Mani Varma From the outputs it seems you are using connect-package version 1.1.1 , would you mind trying with the latest 1.1.2 version ? Overall though, the error you are having is usually generated by a python version lower than 2.7.9 Please let us know how it goes. Cheers. L.

Hi @Bryan Fordney we have a similar integration for Nuke Studio and we are looking into the user base requests for other DCC applications. Are these the kind of features you would be after ? Cheers. L.

Hi @Rory , as long as the module you are importing are in PYTHONPATH it should work. If you have both python2 and 3 available be careful though as the variable is the same for both and can lead to issues. If you still have issues, please send the relevant code to our support providing details about where the third party module is located and how has it been installed. Cheers. L.

hi @Rory here a simple example to translate the entities using the action handler as base class: from ftrack_action_handler.action import BaseAction import ftrack_api class TestAction(BaseAction): label = 'Test Action' identifier = 'com.ftrack.test.action' description = 'Simple test action' def validate_selection(self, entities, event): if not entities: return False results = self._translate_event( self.session, event ) if not results : return False for (entity_type, entity_id) in results[0]: resolved_entity= self.session.get(entity_type, entity_id) print resolved_entity, resolved_entity.entity_type return True def discover(self, session, entities, event): return self.validate_selection(entities, event) def launch(self, session, entities, event): return { 'success': True, 'message': u'Done.' } def register(api_object, **kw): '''Register hook with provided *api_object*.''' if not isinstance(api_object, ftrack_api.session.Session): return action = TestAction(api_object) action.register() hope it helps. L.

Hi @Aaron Powell using the discovery to populate the available applications does not work as it will look into the application store to decide which one to start. The best option at the time seems to be to override the _getApplicationLauncher as by this example to inject the launchArguments you are after. long story short this is what you can simply do: class ApplicationLauncher(ftrack_connect.application.ApplicationLauncher): '''Custom launcher to modify environment before launch.''' def _getApplicationLaunchCommand(self, application, context=None): command = super(ApplicationLauncher, self)._getApplicationLaunchCommand(application, context) command.extend(context.get('launchArguments')) return command The issue is in the original _getApplicationLauncher, which extracts the extra launchArguments from the applications but does not take in account the current context. good news is that we are in the process of reviewing how applications are launched, hence this will be fixed soon. Cheers. L.

Hi @Rory, if you look a the action handler, the entity needed to be passed in is the original one coming from the event, there's no need to try to build the entity from the session. hope it helps. L.

Hi @Rory, if you want to write new actions I'd suggest having a look at our action handler. Regarding your question is because many of the Context entities comes from a common Task base entity (server side), if you want to properly identify have a look at the _get_entity_type method of the action handler. Hope it helps. L.

Hi @Dave Goodbourn the list of available ones can be found here , if you need more complex ui you can think of using custom html widget . Hope it helps. L.

@Aaron Powell would you mind either paste here the full launcher or send it over support so I can have a closer look ? Thanks. L.

@marc mantei _getApplicationLaunchCommand is a method of the ftrack connect ApplicationLauncher class. Using this as baseclass for your launcher will provide you access to the underlying method. You can see an example in the maya hook hope it helps. L.

Hi @tdugard, users query will respect the roles assigned, so they will have different result depending on what they have been set to, especially in regard of the private projects. If you want to ensure these are maintained I'd suggest setting up different global API keys for different behaviours. hope it helps. L.

Hi @tdugard api are not supposed to return filtered results, unless these limits are bound to your user permissions level. What you should do is to filter out the result for the user you are interested in during the query, something along these lines should work. import ftrack_api import os project_name = 'myproject' # login data is passed to the session through environments session = ftrack_api.Session() ftrack_user = session.query('User where username is {}'.format(session._api_user)).first() tasks = session.query('Task where project.name is "{0}" and assignments.resource_id is "{1}" order by name asc'.format(project_name, ftrack_user['id'])) for task in tasks: print t

Hi @Aaron Powell, extra arguments seems to be passed fine : 'launchArguments': ['c:\\Users\\aaron\\Desktop\\lookdev_addon.blend'], but then does not get populated when running the application 2020-06-20 11:55:34,786 - ftrack_connect.application.ApplicationLauncher - DEBUG - Launching ['C:\\Program Files\\Blender Foundation\\Blender 2.82\\blender.exe'] as by https://bitbucket.org/ftrack/ftrack-connect/src/57ece813d21bff72621c1a6a58feb958cd0557cd/source/ftrack_connect/application.py#lines-364 your Launching command should contain your extra arguments. in order to further debug you can overwrite _getApplicationLaunchCommand to print the command before being returned to the actual popen function. Hope it helps. L.

in the ftrack_connect logs you should have the full command which gets executed by subprocess in a line such as : try to manually run it to see if there's any error. let us know how it goes. L.