WebActions backend

[martastain]

Description of changes

TODO

• implement listing simple actions
• implement executing void and launcher action
• rename "void" actions to something sane
• implement take_action
• clear expired events

Later:

• Implement dynamic actions
• Implement HTTP actions

New endpoints

list_available_actions_for_context

[POST] /api/actions/list

Returns a list of available actions for a given context. Context is provided as a JSON object in the request body:

{
    "projectName": "string",
    "entityType": "folder",
    "entitySubtypes": ["asset"],
    "entityIds": [
        "1234567894132456789"
    ]
}

Note

entitySubtypes is not strictly required, but since the frontend
always has the information about the selected entities, it may be
included and save the backend from having to fetch it from the DB.

Additional query parameter mode can be passed to the endpoint. It defaults to simple, that only returns the list of "simple" actions. (actions that don't require any computation to return the result - the list is just determined by entityType and entitySubtypes).

If mode is set to dynamic, the endpoint will return the list of dynamic actions. This list is computed by the addon and may take a while to resolve. So while simple mode is called every time the selection changes, dynamic mode should be called only when the user explicitly requests it and display the actions in a dialog box.

all mode is also supported to return both simple and dynamic actions.

The response model is still WIP, but it is documented. It contains metadata about the actions, such a and identifier, label and icon.

execute_action

[POST] /api/actions/execute

Executes an action on a given context. In the request body, the endpoint expect the same context object as in the list endpoint.

The following query parameters are required:

• addonName
• addonVersion
• variant
• identifier

You can get all the parameters for each of the actions from the list response.

When the action is executed, there are two possible outcomes:

Server action

In the case of "server" action, the logic is executed directly on the server and the response only contains:

{
    "succes": true,
    "message": "Action executed successfully"
}

Message is then displayed to the user.

Launcher actions

In the case of "launcher" actions, the response also contains a URI:

{
    "succces": true,
    "message": "Opening asset 'tree' in Maya",
    "uri": "ayon-launcher://action?server_url=http%3A%2F%2Flocalhost%3A3000&token=b30ccfbc5a792bae825a11a80f3be81950c6ec5afd17719d9306b717998848ac"
}

URI contains server_urland token query parameters. The server_url is the base URL of the Ayon server and the token is a hash of the created event.

The event is created by the server and contains information on the action and the context. Event is created in 'pending' state and is then processed by the Ayon Launcher.

take_action

Launcher calls [GET] /api/actions/take/{token} endpoint to receive the event information. When this endpoint is called, the event is also marked as in_progress which prevents calling the endpoint again (as it only returns
events in pending state).

The launcher is then fully responsible for executing the action and the lifecycle of the event.

When the /take endpoint is not called within a certain time frame, the event is removed from the database.

[Innders]

identifier, label and icon.

Assuming these are all defined by the addon. Can the addon also define the icon? Where is the icon file stored?

[martastain]

identifier, label and icon.

Assuming these are all defined by the addon. Can the addon also define the icon? Where is the icon file stored?

Yes, they are provided by the addon. Icon is tricky TBH. My idea is to allow addon to "register" icons (basically store icons in redis when the server starts) and then it could just use icon name in the manifest and frontend would be able to retrieve it similarly we do it with thumbnails. (something like /api/actions/icon/{iconname} or even more generic in the case we want to store icons not just for actions)

[Innders]

Is the only way to create actions through an addon? I can imagine that someone may want to just upload actions.

Further to that, we may want to write build in tools that make creating actions easier.

[martastain]

I can imagine an addon that would allow creating custom actions from its settings or toml files for example. Action definitions are easily serializable. Not a part of MVP tho.

[iLLiCiTiT]

Method get_simple_actions does not expect settings variant.

EDITED:
And project name.

[iLLiCiTiT]

Works