Julian Martinz

You have to reset session at the beginning of your callback() with Session.reset() and it should work as expected

@John maybe I don’t get the problem but can’t you just get the project via the entity you’re dealing with? Or are you just looking for a more convenient way? Best, Julian

Hey Alican, I didn't read through the entire thread but I think all you wanna do is adding a reviewable version to an assetversion. If that's correct you just can use the encode_media helper method from the asset_version itself and call it a day. With that method the media will be uploaded and encoded. ... asset_version = session.create('AssetVersion', {'asset': asset}) asset_version.encode_media(local_path_to_media) Best, Julian

Your PYTHONPATH has to be set accordingly. Which OS? And how do you start maya? If you start Maya from the same terminal-session from where you can import the api in an interactive python session, you should be able to import the api inside Maya as well. Edit: Obviously the PYTHONPATH has to be set in the bash-session (or whatever shell you use)

hey @Lorenzo Angeli Okay think I got it. I thought of the proxy location as a mere "switch" that forwards the add_component method to one of the two locations and then the component is addaed to the actual location (server1.managed/server1.unmanaged). But what you are proposing is to actually add the component to the proxy-location and just leveraging the methods from the other (configured) locations. Did I get it? Best Julian

Hey Lorenzo, That's absolutely fine .. but how can I create these two locations with the same name but different behaviour? When trying to create to locations with the same name the session will logically throw an error. Or are you talking about two entirely different location? To stick to my example: studio.server1.managed and studio.server1.unmanaged? If so that's actually not what I am after. The point is that I only want to differentiate on publish/component-creation. Once the components are published, you shouldn't be able to distinguish between components added via the unmanaged or via the managed location. So basically just as if you are adding components to a configured location or the same location after mixin in the unmanagedLocation mixin. Once added there is essentially no difference between the components. But maybe that's just not possible? Or maybe I am missing the point. Best, Julian

Hey @Lorenzo Angeli, looking forward to your example. In the meantime I tried it myself and got a working version up n running. Unfortunately it doesn't really help me with the original problem. I can configure my proxy location to choose between distinct locations with different names like studio.server1 and studio.server2 (which is great btw and helps me solve some other issues I had). However, to choose between a managed and unmanaged version of the same location I'd have to create both instances beforehand, which afaik is not possible as they are essentially the same? Or at least I don't know how. What would work is creating two distinct locations studio.server1 and studio.server1.unmanaged. But that's not really what I am after. And that brings me back to my original question: Is there any way to revert a location instance back to the state it was before mixin in the unmangedLocationMixin? The only solution I can think of right now would be to reconfigure my locations by emitting an 'ftrack.api.session.configure-location' event. But that doesn't seem right .. - Julian

Hey Lorenzo, thanks for the reply. I think @JPrydz mentioned that concept before. You don't happen to have a code example ready? Or at least a draft or a hint? After a short glance at the location class I'd start by overriding/extending the add_component method and implement the logic there. Does that sound sensible? Best, Julian

Is there an option to revert a location to default after setting it up to be unmanaged with the ftrack_api.mixin() method? I have to publish components to the same location during a session. Some of them are already where they belong so I want to add them through the unmanaged location. For others (especially those created by the official plugins // publishers) I'd like to rely on the default behaviour. - Julian

Hey Lorenzo, Thats basically what I was planning to do (except for the threading part in the action .. but guess that's the only viable way). Thanks for the reply. - Julian

I am about to shift some specific actions from running locally on user-workstations to one or two central worker-clients. Some of these actions will run a little bit longer and won't be discoverable during processing. To keep it simple, maintainable and scalable I'd like to avoid setting up threading/multiprocessing mechanisms inside the action and do that on a higher level instead. Is there a canonical way to pull this off? If I understand it correctly the event.stop() method will only work if I register the listeners from one single process. So multiple-docker containers or multiple hosts won't work because this would lead to multiple actions with the same name showing up for users. Is that correct? Anything else to watch out for?

Ah ok .. guess that’s by design. you could setup an event handler that is listening to status changes and sets a ‘latest_approved’ flag on the most recent approved version. Then you could use that attribute in your queries. Quite involved for what you want but it should work. Would be welcome if something like that could be accomplished with the filter queries instead.

I may be wrong but can’t you combine the query filter with the built-in latest version filter and are done?

Digging around I found the answer to my question by myself. For reference it is possible to modify the labels on review-session-objets. More information can be found here http://ftrack-python-api.rtd.ftrack.com/en/1.7.0/example/review_session.html?highlight=reviewsession and in the action here https://bitbucket.org/ftrack/ftrack-recipes/src/master/python/actions/annotate_review_clips/

Hey Johan, Actually, this is exactly what I (and Tim, if I understood him correctly, too) want to do. The question is where to find the default one. Best, Julian

Hey there any news on this one? Is it possible to customise the default dialogue or is the only solution to build a custom version from scratch and override the default one with the layouts?

Is there any option do add comments/descriptions to versions in the client-review? Apparently the only information that are carried on to the review-session are the TaskName, parent object name and version index. It would be great if it is possible to forward comments / descriptions from the AssetVersion to the client-review. Or display the Asset Name as well. For example when I want to share 2 Versions of the same edit with different audio files or different endings the only ways to make clearly distinguishable for the reviewer is to either comment the versions myself right in the review, add slates or create separate parent objects or tasks for each version. And frankly, I don't find any of them appealing. Including the AssetName as information for the reviewer would be a step forward but an option to manually pick attributes/comments which will be forwarded would be even more useful. Maybe I am missing something and it is already possible? AFAIK there is also no option to work something out via the api?

Hi there, you have to specify key, value pairs if you want to query custom attributes and metadata. The right syntax is s.query('AssetVersion where custom_attributes any (key=downstream and value=True)').first() Also notice that bools are written in upper case. So true won't work as value.

Hey there. Please invite martinz.julian@gmail.com. thanks