tokejepsen

BTW make sure you use this http://ftrack-python-api.rtd.ftrack.com/en/latest/api_reference/entity/location.html?highlight=remove#ftrack_api.entity.location.Location.remove_component, instead of "session.delete".

Being able to change the time log for other people as a supervisor or coordinator would be good.

Being able to change the time log for other people as a supervisor or coordinator would be good.

Being able to change the time log for other people as a supervisor or coordinator would be good.

Being able to change the time log for other people as a supervisor or coordinator would be good.

Could you elaborate on this?

Trying to trigger an action dialog from a custom published event, and can't seem to get it to work.

Being able to change the time log for other people as a supervisor or coordinator would be good.

No problems aside from those you already handle; that it overrides all built-in event plugin hooks if you're not careful.
The FTRACK_CONNECT_PLUGIN_PATH and default plugin folder is meant to be a standardised way of sharing plugins. The nesting of <root-folder>/<plugin-folder>/hook/ is there to allow separation of plugins from different vendors, and the hook/ folder is there since Connect walks the folder structure down looking for any .py/.pyc file that has a register function. So if you have complex integrations with their own hooks you do not want to source those (let me know if you want me to elaborate on this).
If you prefer FTRACK_EVENT_PLUGIN_PATH that is still fine, if you want to use FTRACK_CONNECT_PLUGIN_PATH you can still do sort of a flat structure and put all hooks in one dir: <root-folder>/my_studio/hook/

I think you should prefer using FTRACK_CONNECT_PLUGIN_PATH whenever possible. In what way doesn't it work, nothing happens? Be careful to structure the plugins correctly, see this article: http://ftrack-connect.rtd.ftrack.com/en/latest/developing/plugins.html#plugins
 
 

I think modifying it should be fine since options it will then be used when doing is used with subprocess.Popen
The application and context is just sent for reference, the command and options can be modified to tweak what is launched.
If you've got the time it would be very nice if you could fork and create a pull-request for this. A ftrack.connect.application.after-launch hook, with the pid and some meta data. If you do this it would be great if you could add some documentation about the event as well! :-)

So I had some time to play with this a little bit and came up with compact and quite efficient way of dealing with environments using launching events. Technically all that is needed is one hook that listens to the launching events and appends environments from simple .json config files based on app identifiers.
The hook looks for .json files in 'FTRACK_APP_ENVIRONMENTS' and tries to find 2 configs. One that is version independent i.e. 'maya.json' and one that is version dependent i.e. 'maya_2016.json', then it adds both into the environment. Config file names mus match the app identifier or the first part of the identifier when split by '_'.
You can then have a hierarchical environment config files, where maya.json loads regardless of maya version you launch, and maya_2016.json gets added on top of the environment when you launch Maya 2016 from ftrack.
'FTRACK_APP_ENVIRONMENTS' folder can then look like this for instance:
maya.json maya_2015.json maya_2016.json maya_2016.5.json nuke.json nuke_9.0v8.json houdini.json houdini_15.json etc....  
This is the core part of the hook (full hook attached):
def modify_application_launch(event): '''Modify the application environment and start timer for the task.''' data = event['data'] context = data['context'] app = data['application'] environment = data['options']['env'] env_path = os.environ.get('FTRACK_APP_ENVIRONMENTS') env_files = [] # determine config file for version independent environment app_name = app['identifier'].split('_')[0] app_file_name = '{}.json'.format(app_name) env_files.append(os.path.join(env_path, app_file_name)) # determine config file for version dependent environment variant_file_name = '{}.json'.format(app['identifier']) env_files.append(os.path.join(env_path, variant_file_name)) env_add = [] # loop through config files for env_file in env_files: try: env_add = load_env(env_file) except: env_add = None # Add each path in config file to the environment if env_add: for variable in env_add: for path in env_add[variable]: ftrack_connect.application.appendPath( str(path), str(variable), environment )  
This is what the config file look like then:
{ "MAYA_PLUG_IN_PATH": [ "K:\\.core\\dev\\maya\\plug-ins" ], "MAYA_AUTOSAVE_FOLDER": [ "C:\\mayatemp\\autosave" ], "MAYA_SCRIPT_PATH": [ "K:\\.core\\dev\\maya\\scripts", "K:\\.core\\dev\\maya\\shelves", "K:\\.core\\repos\\maya\\scripts", "K:\\.core\\repos\\maya\\prefs\\shelves" ] }  
Now quite frankly, I think that a simple hook like this (probably a bit more robust version) should be a part of the default connect installation. Straight away people would have 3 options of modifying the app launches. 
Only need to modify environment: Add your json formatted environment file to 'FTRACK_APP_ENVIRONMENTS' and name it 'app_identifier.json' (e.g.: maya_2016.json) Write your own hook that catches launching events and modify the launch that way. Change the launcher hook in connect and modify to your heart's content  
One way or another, our enviro setups just went from lot's of python file, to a simple json file per app without the need to tinker with default hooks. Thumbs up.
modify_app_launch.py

The feature I mentioned above is released and you can find more information here: 
http://ftrack-connect.rtd.ftrack.com/en/0.1.21/using/plugin_directory.html
http://ftrack-connect.rtd.ftrack.com/en/0.1.21/developing/plugins.html
http://ftrack-connect.rtd.ftrack.com/en/0.1.21/developing/hooks/application_launch.html#ftrack-connect-application-launch
 
You can reply here with questions or feedback!