I am trying to implement a simple automation feature for my powerup that takes an action for the member who performed a certain action (like moving a card from one list to another) without causing that same action to trigger for other active board members.
I have been experimenting on this for a few days now, checking all the tools available through the powerup client library, and all incidental information available to the powerup, and have come to the conclusion that right now it just cannot be done.
If there is a solution to this problem I would be super happy to learn about it. Otherwise I would like to propose an addition to the client library, where whenever t.render() or any of the capabilities gets triggered, the client library provides a simple context object that contains the reason for the redraw and some context.
For a list move action for example it could look similar to this:
Interesting idea. I’d guess that it is probably already very likely that there is an action generated for each call to render–though certainly not exactly 1:1.
Could you expand a bit more on how the solution you proposed would be useful to you?
It does not have to cover every single reason for redrawing to be useful, just for the ones that are included to be reliable. So a ”not exactly 1:1” situation should be good enough for this purpose.
Well, I am trying to trigger an action when a card gets moved from one list to another, but only for the member who did the moving. I am already keeping track of movements between lists by keeping the old list in the public card data section of the powerup. I hoped that I would be able to piece together who did the moving in a similar way.
I could not find any way to derive the initiator information from the client library. The REST-Api allows access to a cards history, which in turn could be used to resolve the initiator of the card movement. But given the additional authentication requirements, the rate limiting of the api and the fact that I would have to do this on every single list change render() call for every single active member makes this effectively a non-solution.
I thought that maybe once render() triggered for the member initiating the action, I could just trigger my own action and then set a flag for all other members indicating that this action is already resolved. But the client library does not work that way. When a member triggers a list change, all active members will get a render() call with the same snapshot of the board state as the original initiator, not with the state that the initiator left behind, so the do-not-act flag would not be seen by the other members before they had already acted.
Lastly I thought that by clever manipulation of the card’s data and analysis of how it changed between subsequent calls I might be able to deduce the original initiator. But besides this resulting in a lot of additional data manipulations and subsequent render() calls this would also be pretty unreliable. My tests suggested that for members on similar internet connections the scheduling order of the calls might be reliable enough to make assumptions about the originator of an action, but for members on very different connections there is no guarantee of scheduling order at all.
I don’t know if there is a good reason not to give powerups insight into state transitions, but this information is already available through the card history of the REST api. Giving powerups access not only to current board state, but also allowing them to understand how that state came to be would allow powerups to perform actions based on very specific contexts. In my current case it is only about starting a timer for one board member, and not for another. I have quite a few of requests asking to make my powerup smarter. And in many cases this smartness depends on not only knowing what the state of the board is right now, but also how it came to be.
If any of this is unclear, please let me know and I will try to elaborate on it.