Yeah, I was just curious if there had been any broader thought around the overall concept, since this was at least the second one to come up. It reminds me of how Coda has the integrations that sometimes bring in special functions, which provides easier access to data that typically is hidden behind APIs. Much of this stuff can be handled via the API or integromat, but being able to more readily share that kind of work natively in fibery is interesting. I didn’t have any specific use cases yet but thought it was interesting.
General Rules Feedback
I have been working on building an EOS app since rules were officially released and I’ve been pretty happy with how far I’ve gotten in the amount of time. The more official tools out there are pretty rough, and can already see some major improvements over them. It has a number of meeting-focused processes that automation has made easier compared to integromat, but have found myself with similar needs as @Chr1sG in terms of iterating over children. I also find it pretty complicated when trying to stub-out entities where I want to only do so if it doesn’t already exist.
Iteration
One concept EOS has is that you rate your meetings at the end between 1 and 10 based on some specific criteria. So, I have a Team, Meeting, Employees, and Votes type. The Votes are associated with an employee and a meeting. The meeting is typically once a week for a particular team. So, for each meeting that is created, I want to stub out the votes for each person on the team. To do that, I have an action script to load the employees associated with the team, then create a Vote entity for each employee and associate it with the meeting. I think use the smart folder to list out the meetings for the team, and have a view for each meeting which is a table of votes ready to apply for each person.
Create if Doesn’t Exist
The other thing I’m doing is modeling the week explicitly as a Type. I’m doing this because there is so much in EOS that is built around the week cadence, and having the weeks modeled as an option has been useful for different visualizations. So, when I create a new meeting, I’m getting the current day, looking up the week to see if it already exists by directly executing the command to find the week where the current day is between the start and end dates, then creating it if it doesn’t, then linking the week to the meeting.
In general i was trying to avoid needing to pre-create helpers like the Week entities. I could instead pre-create a whole bunch of them, then auto-link the Weeks based on the date. So, while there are other ways to do what I’m doing, I think the whole create if-needed, then link this entity could be a pattern that comes up and isn’t super easy to implement in action scripts. It also isn’t possible directly from the rules editor that i can see.