Chandler

Members
  • Content Count

    5
  • Joined

  • Last visited

Everything posted by Chandler

  1. Hey @Lorenzo Angeli could you clarify where the most up-to-date boilerplate code of your proxy solution is right now? I've seen you post it before, but I don't see a link in this thread, and this is all I can find now: http://docs.efestolab.uk/tools/proxy-location/index.html I'd like to explore implementing this on our end.
  2. Sure. I have actually already created this in a way the way I want, but it would still be improved by a way of 'intercepting' a change rather than 'reverting' it as we have to now. I wrote a script that essentially determines the 'allowed statuses' for a Task or Milestone based on Incoming links. A Task/Milestone with any incoming links is first forced into a special status called "Locked". It is not allowed to be changed away from this status. If all of the incoming entities are marked as completed, then this changes from "Locked" to "Open". The script then finishes up by trickling down this configured status check to any outgoing links. This all works great, but there's a huge processing and usability problem with having to detect and revert these changes. As of right now, the user is told their status changes are all successful, and then they watch them slowly change to their allowed statuses where applicable. Sometimes these changes lag long enough that a full refresh is necessary. These status changes also persist in the history, which I may need to depend on for other logic later. This also rules out the ability for me to program any logic for when a Task first unlocks and obtains an "Open" status. So back to the regex thing - I imagine the same logic being used to deny a name change based on regex, could also apply to a status change and prevent that from happening. Just like a name change might be compared against the regex, the status name could simply be compared as well. What logic did you guys have in mind to actually set the regex for naming validation? Would it be stored within the entity itself and changed via the API or something? This would allow a script to dynamically change the approved regex's for a given field, which would be really sweet. Maybe even the field itself could support a 'validation' key with the regex directly in it??
  3. Thanks for the quick fix on the docs, certainly clears up some confusion I had, haha. Regex would be very appreciated and powerful. I am also facing a need to validate statuses though, so I wonder if there's a way for a regex to apply to that field as well. It would be a little more abstract than than naming validation I guess, but I could see it still working. That may be out of scope though, if the discussion here is determined to be focused purely on validating text fields or something. The way that old validate function worked seems to be the right idea implementation-wise. I understand if the new API ruled out that type of event interception though. Overall the need seems to be having the chance to validate an event before it actually happens. That's the common thread with all of these issues - the fact that currently ANY validation needs to be the product of detecting a change and reverting it, as well as completely custom logic, is quite daunting and taking up a decent amount of my development time. I'm not familiar enough with the API yet to be thinking about performance, but I'm sure that would increase too when we aren't reverting so many changes.
  4. I'm a bit confused as to the the ftrack.validate event subscription seems to remain in the documentation. I won't have a chance to test this for a while, but Project Code validation is a huge need for us, and the current docs seem to indicate this is possible...? https://help.ftrack.com/en/articles/1040479-events Scrolling to the bottom, I see the ftrack.validate topic listed. Are we saying if I set up an event listener for this topic I won't get anything?
  5. I'd love an invite to this channel. Thanks in advance! chandlerphilly@gmail.com