workflow.conf ============= ALLOW\_AS\_NEW\_VERSION: [..., ...] List of processes that Production Manager will allow the user to publish to them directly by drag-n-drop files directly from desktop without forcing the user to publish out of an application like maya. TYPES_PUBLISH_DENY: [..., ...] types listed here will be denied for drag and drop publishes, it's recommended to put all supported applications types into this list, like ['maya', 'houdini', 'katana' ...etc] PLAIN_DIR_PUBLISH: On/Off [Disable/Enable, False/True] When enabled, publishing folders via drag-n-drop will accept folders that doesn't have extension in their names. By default, we deny plain dir name from being published, we keep this for internal processes, while the folder should have extension reflects what's inside it. RENAME\_DIR\_FILES: Publishing a directory to any process of the list of processes mentioned here will have all its files renamed to \_ before being published (like publishing to 'layer' or 'backPlate' processes where each version of the sequence folder have to have consistent naming convention to update the edit timeline properly when jumping to higher or lower version or using the versionless folder). The rename process here doesn't rename the subfolders but will rename the contents inside them, so keep careful (I don't rename the subfolders to give the user a chance to put some folders for something like 'lowRes', 'hiRes'... etc.) while having their files renamed as expected. The rename also respects the symbolic links. MANAGER_ATTITUDE: "free|strict|tough|aggressive|nagger|fair" This is the Seneferu production manager attitude, the recommended modes are 'strict' and 'fair'... - free: he will be nice and cool (don't run in this mode except when your project is not ready and the users need to jump back and forth between tasks and running a lot of R&D tasks rather than actual production tasks) - strict: He will deny users from publishing any task they do if any of the dependencies used to build up this task is not yet approved, this mode also forces the supervisors to process the tasks in their review list by either "Approve" or sending them back to the task assigned user. - tough: like strict mode in addition to that if the user is also supervisor, and he has pending tasks to review in his review list, Seneferu Production Manager will not allow him to work on a task before reviewing the tasks in his review list and decide on them (these tasks are denying others from proceeding with their jobs). - aggressive: all like previous modes combined, in addition, the production manager will force the users to work on their tasks by the order he see it better for the production, by analysing the project and seeing which task opens more opportunities to more users to work and which task belongs to a higher importance asset, or have more tasks pending on it (unless a task priority is overridden by the production or the supervisor). - nagger: in addition to previous modes attitude, the production manager keeps nagging via pop-up messages to the user regarding to any delayed task, any tasks left in his review list, any tasks needs revisiting but the user is keeping them opened, any task that has comment, and the user is working on something else lower priority. - fair: Seneferu Production Manager will decide his attitude by going with one of the above automatically based on the user's performance and sometimes based on the project state, so he will be nice and cool with good performing users, aggressive with below good performing users and nagger with bad performing users. While he maybe “tough” with the supervisors when their review list grows more than usual and they are not reviewing them the thing that slows down the production and causes bottle necks later when bunch of tasks are approved at once leading for a bunch of new tasks ready start at once either, this in addition to the delays the can be resulted due to the slowness in reviewing the finished tasks. NAGGING_INTERVALS: the time in minutes on how long time the Production manager waits before sending the next nagging pop-up to the user in case of nagging mode. STRICT_MODE: if enabled, loading unapproved dependencies for an asset will raise a warning, while publishing an assets built on Unapproved assets will be denied. DENIED_WEB_STATUSES: [] A list of statuses that nobody can set them on a task using the nreal tactic web ui, this forces the users to set the statuses using the production manager. This is needed specially for Approval statuses where setting them directly in the UI will blindly approve the latest version which is not always the correct behavior, so, Approving in the Production Manager will properly tag the approved version and write a note on it. BROWSE_UNSUPPORTED: if enabled, load dependencies of an asset for a 'Others' application mode will open a system file browser pointing to the location of the dependency files. PREFER\_USD: if True, usdExport will be used instead of AbcExport to write out assets, and referencing dependencies will look for a usd file first before checking for alembic. MULTITASKS\_ALLOWED\_USERS: list of users who are allowed to have more than one task "In Progress". RENDER.HANDOFF_DIR: is a relative path to the sandbox directory, and this is where the renders temporarily go till being injected to Tactic out of there. RENDER.CHECKIN\_METHOD: "Remote" means files will be uploaded using the Queue (Tractor) or will use the 'upload', checkin mode when checking in the rendered sequences to Tactic. while "Local" means files will be checked in normally in 'move' mode. RENDER.RENDER\_CMDS: The render command for each specific application. RENDER.AUTO\_SUBMIT: If "True", the 'lighting' process post-trigger will automatically launch the submit\_to\_tractor for each active render layer 'render' task of this 'lighting' process. example: if 'lighting' process has env and chr render layers, and both are set to active, then when the 'lighting' process is approved, then 'render/env' and 'render/chr' tasks will automatically be submitted to tractor. RENDER.SUBMIT\_AS\_PAUSED: if True, any 'render' task submission to tractor will be queued 'paused', giving the wrangler the freedom to manage what to start. SIMULATION.HANDOFF_DIR: is a relative path to the sandbox directory, and this is where the simulations temporarily go till being injected to Tactic out of there. SIMULATION.CHECKINMETHOD: how to checkin the files after simming ('local', 'remote') SIMULATION.SIM\_CMDS(as below), are the tractor cmds when simulating and the tractor services "katana": {"render\_cmd": "katana", "service": "katana"}, "maya": {"render\_cmd": "Render", "service": "PixarRender"} SIMULATION.SIM\_CMDS.AUTO\_SUBMIT: Auto submit the sim process to the farm. SIMULATION.SIM\_CMDS.SUBMIT\_AS\_PAUSED: submit the sim as paused. DATABASE.PUBLISH_CMD: The system command for publish/checkin files into the asset management system database and project tree. MAX_TASKS_DISPLAY: limits the task manager tasks display to this count, dependencies are not truncated and will always be visible even if theire count exceeds the max allowed here. MAX_TASKS_LOG: enables/disables the Max_tasks_display logging messages, by default, the task manager will not tell when the tasks list is truncated since the use will always use the search filters when the task count is greater than what a human can search manually and then truncated tasks will be displayed based on the filters, also dependency tasks list are always full list and not truncated no matter how big it is. Anyway, if you still need to be told by Production Manager whenever the list is truncated or full, you can enable this logging flag here. Tasks Display: -------------- The tasks displayed on Production Manager are truncated to the configured max count in the workflow.conf - MAX_TASKS_DISPLAY entry. This is needed for performance and interactivity specially when the user/project tasks grows to thousands of tasks. Anyway, truncating the list is happening in smart context the way that you will always see that tasks that you have to see, and lower possible needed tasks will be in the bottom of the list and these will be truncated first. So, if the max count is 25 (the default), then all the first 25 tasks are the higher priority tasks, the earlier to be delivered tasks then the low priority tasks and non-ready to start tasks come last. Notice that when the tasks are greater than 25, then no one would be able to search in them manually, but you will always have to use the filters to get what you want. Note:: The truncated list doesn't mean that the tasks are not there in the list anymore, they are cached in the background but not displayed for better viewing and better performance... You can still have access to the tasks not the list using the search filters.