Skip to main content

Workfiles - Ability to filter workfiles by task name based on workfile filename ( or metadata )

Feature requests PipelineCommunity

At the moment the workfiles app just shows all files it sees in the work dir, no matter what task they got created in. The launcher shows only registered workfiles, but it does provide a cleaner experience if you opted not to use task specific work folders. A feature that resolves the task from a workfile by its name or metadata would be great, so workfiles can filter these properly.

Posted by Dieuwer Feldbrugge
10 comments

Log in to comment and vote

Comments10

  • Dieuwer Feldbrugge

    If not, then lets have the launcher show all files on disk too. Because a similar experience is expected by a user in similar interfaces.

  • Dieuwer Feldbrugge

    At the moment this behavior invites pipeline breaking actions by people if you dont have seperate task work folders. Here’s me trying to open the layout file while i have the FX step selected. You’ll get clashing workfiles + environments.

    • Mustafa Zaky Jafar

      Team

      I think the most important part here to select the correct task in the workfiles tool as it’s used to set the context in the current Houdini file/session.

      But, since user can see all the workfiles regardless of the selected task, then context can mess up as you have shown.

      • Dieuwer Feldbrugge

        Yes, and they will and they have in our case, it’s very easy to select the wrong task while opening the wrong file. Hence my feature request for workfiles to also infer the task context from the filename template instead of just the folder template

  • Mustafa Zaky Jafar

    Team

    At the moment the workfiles app just shows all files it sees in the work dir, no matter what task they got created in.

    I guess there’s a misunderstanding here, as far as I know, it’s template based, the workfile is computing the file location from the template based on the selected context (project, folder, task). Then it lists any workfile in that location.


    If the work template doesn’t include task name key, then the work location for any task will be the same. leading the workfiles tool to show the same list of files..

    • Dieuwer Feldbrugge

      Dont you think its logical to infer not only from directory path, but from workfile too? Now we’re basically forced to use task specific folders, which isnt something that happens at all companies and in our case actually increases overhead and amount of folders quite a bit.

      I wouldnt mind if we can still see all files in the folder in workfiles, but then the Tasks selection should also jump to the task thats part of the workfile so it doesnt break the pipeline as it does now.

      I think it makes more sense to just align it with how the Launcher would see it, but that would require resolving a workfiles task from the workfile name AND the path not just the path.

  • Mustafa Zaky Jafar

    Team

    Thank you @Dieuwer Feldbrugge I made this is TL;DR

    it's about the logic used for listing workfiles in workfiles tool and launcher.

    In workfiles tool:

    • it's a simple and direct way, it only lists workfiles in a given directory.

    • this way may be confusing when a studio wants a minimal project folders setup where they save all of workfiles directly under a folder (without a task folder).

    In launcher tool:

    • it shows registered workfiles (which doesn't match the workfiles tool behavior)

    • downside, if a workfile is not registered (which is possible if users are doing things manually), the workfiles won't show up in the list.

    A possible solution from internal discussion can be to filter the workfiles list in workfiles tool by excluding registered workfiles that are not related to the selected task. but this would need some work, it may need to be sponsored.

    • Dieuwer Feldbrugge

      Thanks Mustafa, I do see whats happening and I get why it happens. I just dont think its a robust choice to not cover this option from ynputs perspective. At the moment the workfiles app is dangerous to use like this if you dont need to have task folders.

      I understand that just showing what files are in a a work folder has its own benefits/is a conscious choice. I just see that all the data is here for ayon to be able to not open a workfile in the wrong task by accident so people dont run into issues like these like I have.

      I’m sure there must be logic somewhere that can also infer a task from the WHOLE path + workfile template not just the workfile source template right? Or is that the point, there’s no inverse context traversal in Ayon like I’m used to with other pipelines? This is what generally happened with SGTK, it can tell by a path and/or

      filename what task it was made in. No fancy web API stuff needed, just a path, and a template.

      Its not something I’d personally need to invest a sponsorship in, I’m providing some of this feedback more for the benefit of the project. We can start using task folders just fine. But to me its not obvious that its expected of studios to always have specific task folders at all times.

      • Mustafa Zaky Jafar

        Team

        I understand your point of view. These kinds of situations happen when something that's considered normal in one program is not in another.
        Currently, the system expects that task folders have unique paths. standard way to mirror the project hierarchy on the server.
        Thank you for pointing that out as I believe it’s worth mentioned on docs.

        • Dieuwer Feldbrugge

          I'm sure you agree with the logic, and increased flexibility of my suggested methods, without it impeding general ayon philosophy. But I get that there are priorities. Mentioning this in the docs would be good, but since I'm after robustness I'd suggest if you don't want to expand on the context resolving capabilities of ayon that adding a validity check to the anatomy that you can't save an anatomy path without a task key present makes even more sense than just adding it to docs.