Jump to content

jen_at_haverstack

Members
  • Posts

    47
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by jen_at_haverstack

  1. We have a custom version of `ftrack-python-api` to use in-house because of a bug in the `websocket_client` package. I thought I would mention it here to see if it can be resolved so we don't have to maintain our own fork.

    To summarize, we are using `ftrack-python-api` inside of a Deadline plugin so that Deadline renders are published automatically to Ftrack. However, when using the package we encountered persistent `SSLError: [SSL: CERTIFICATE_VERIFY_FAILED]` errors. We tracked down the root of the error to this line in `websocket_client` where the package defaults to SSL version 2.3 if no SSL version is provided in the options.

    As summarized in this table, SSL versions 2 and 3 are insecure and are disabled by default in many libraries. This is why we still couldn't get the `ftrack-python-api` package to work even if we enabled SSL 2 and 3 on the Ftrack server. The crypto client libraries themselves do not support these protocols anymore by default.

    In order to quickly fix this issue on our end, we opted for passing the `ssl_version` option when the EventHub WebSocket connection is being created. Our code changes this line in `ftrack-python-api/source/ftrack_api/event/hub.py` to:

    self._connection = websocket.create_connection(url, timeout=60, sslopt={"ssl_version": ssl.PROTOCOL_TLS})

     

  2. @Lucas Correia When I deployed my code with your suggestion I encountered a problem: the Javascript API doesn't support targeting events, so publishing the `ftrack.action.trigger-user-interface` will generate UI on everyone's Ftrack, not just the user that launched the event.

    I didn't notice this before because I had been testing on a staging server. How can this event be fixed so that only the user that triggers the widget sees the UI?

  3. On our Mac machines, it's currently impossible to open multiple instances of the ftrack-connect application. Launching the app multiple times has no effect because the launches are effectively canceled by the ftrack-connect instance that is currently running. On Windows we do not see this behavior and it creates an adverse user experience. In the following screenshot you can see that multiple instances of ftrack-connect are running at once:

    image.png.e64013840d8ed043bd2c7b3f2e2c6051.png

    In many cases the second instance is opened accidentally, but it shouldn't be possible at all.

  4. Sorry for reviving an old thread but an Undo feature is pretty high on my studio's list of feature requests. We sometimes run into an issue where our workers delete a task when they actually meant to delete a version or vice versa. A simple way to revert the past operation would be great.

  5. I am looking to obtain a file path for this particular example, but we have ideas for other kinds of widgets: user selection, task/object selection, etc.

    I hadn't considered using `ftrack.action.trigger-user-interface`, but that solves my problem!

    Here's a code snippet of a function that will create a user interface form and then pass off the form data plus the widget data to a different action:

    function submitActionData(actionIdentifier, selection, data, session) {
      /*
      actionIdentifer: the action ID that you want to pass information to
      selection: the selection that was used to launch the original action widget
      data: a payload object collected from a JavaScript widget
      session: a propertly initialized session object
      */
      // Create the UI items that will appear in the form. This the same format that is used to
      // 'normal' actions: https://help.ftrack.com/en/articles/1040465-actions
      const items = [
        {
          label: "A string",
          type: "text",
          name: "my_string",
          value: ""
        },
        {
          type: "hidden",
          name: "my_hidden_value",
          value: "foo"
        }
      ];
      // Append the data that was collected in the Javascript widget as hidden values of the UI
      for (const key in data) {
      	items.push({
          type: "hidden",
          name: key,
          value: data[key]
        });
      }
      // Create the data object for the event
      const eventData = {
      	items: items,
        actionIdentifier: actionIdentifier,
        selection: selection
      };
      // Create a new event with a topic that will trigger the user interface
      const event = new Event('ftrack.action.trigger-user-interface', eventData);
      // Publish the event to the session
      return session.eventHub.publish(event);
    }

    When the above function is called from the widget, a new web UI form is displayed. Submitting this form will pass its form data (which includes data collected in the JavaScript widget) to the specified action. In this way we can collect data from the user in a JavaScript widget but then have complex querying or file handling done in Python.

    Thanks for your help!

  6. I noticed on the documentation that using ftrack's AMQP server will be enabled by default in future versions, so I decided to enable it for my local ftrack installation. However, I noticed that I'm not getting `ftrack.update` events if I subscribe through event hub (even using a simple example such as https://bitbucket.org/snippets/ftrack/n7qLe/event-listener-print-update-event-data).

    I am able to see update events if I set up a listener directly to the AMQP server, but I don't see any documentation saying that we would not get event hub update events if the AMQP server was enabled. Is this the intended behavior?

  7. I've developed a widget that is launched from an action and the widget shows a form that collects some data. For example, this widget collects an entity ID selection from a drop-down menu:

    1145703268_Screenshot2019-12-1616_19_14.png.d2606bced9169f1e82ac92df327efb5e.png

    The Submit button creates an `ftrack.Event` object with the topic of 'ftrack.action.launch' and the appropriate data to launch another action, publishes this event, and closes the widget window. On my event listener I can see that the action is being launched and that it is generating the correct data to show a form, but the form never shows up in my browser.

    My hunch is that when I jump from an action to a widget and back to an action again, I'm losing target information about where my browser window is, so the last form doesn't show up. Do you have any idea how I can collect the appropriate information in the widget so that the action launch event that is generated is properly routed?

    ---
    Taking a step back, my specific use-case is that we have developed a number of actions in-house that collect data via forms, but they are missing some UI components that I was hoping to make up for via widgets. For example, an action that needs to collect file browser data would collect the file location via a widget first and then proceed to the rest of the action. (At the moment, users are copy/pasting the file path into a text box for this action.)

  8. I've written a custom location plugin for ftrack-connect and the 'real' paths to file components show up correctly in the ftrack UI. I can also use the 'Open Directory' action successfully, etc.

    My issue stems from publishing a version in Photoshop. The publish appears to fail (see attached), but the file is created in the correct place and the ftrack UI shows the new version and its corresponding component. If it didn't actually fail (from a practical standpoint), why am I getting this error?

    The other thing to note is that I'm on a Windows 10 system, so the listed components configuration location is correct, but for some reason ftrack-connect wants it to be at a macOS location instead.

    The ftrack-connect logs don't show an error, so I'm not sure how to troubleshoot this.

     

     

    publish-error.png

×
×
  • Create New...