Flows: Improve the Log Activity Panel #15870
Replies: 8 comments 4 replies
-
Beta Was this translation helpful? Give feedback.
-
@directus/team |
Beta Was this translation helpful? Give feedback.
-
I vehemently agree with points:
If the Log was 1:1 with the data chain it would have saved me (subjectively speaking) a lot of time, see also #16674. Specifically, I struggled with the Read Data op knowing what to put for the UUID, which was |
Beta Was this translation helpful? Give feedback.
-
Heya! Thank you for taking the time to submit this request! It has been over 90 days, and this discussion has not received at least 15 votes from the community. This means that we don't feel like there's enough community interest to warrant further R&D into this topic at this time. 🧊 This request will now be closed to keep our discussions tidy. Please reach out if you have any questions! For more information, see our Feature Request Process. |
Beta Was this translation helpful? Give feedback.
-
This request has continued to come up, so on February 8 we're inviting the community to come and have a chat with us about this feature request at our Request Review in our Discord server. This will help us have some dedicated time to talk about what implementation would have the most sense. Please feel free to join us as https://directus.chat/ (the event is already listed and you can set a reminder) |
Beta Was this translation helpful? Give feedback.
-
I would love to see options to clear out logs, and the ability to "lock" a log so I can save specific ones while still being able to clean up all. |
Beta Was this translation helpful? Give feedback.
-
Idea to improve the life of devs :)) Would be great if we can add a note to each step in flows. These would be used only internally This is an example of how its done in another platforms flows. |
Beta Was this translation helpful? Give feedback.
-
2 More ideas, and these ones are actual problems. 1.When editing flows, you click edit, and the Edit Operation Side Menu shows up, well that immediately resets the view of the drag and drop interface to the top, so when you close that Side Menu, you are reset to the top position. When having larger flows that stack, that is really annoying, because you have to pan and search again for the flow step .
|
Beta Was this translation helpful? Give feedback.
-
Flows is totally cool! But the log panel has (in my opinion) UI/UX issues.
I find myself immediately reaching for Postman to debug/setup just about any flow.
In this discussion, I'm going to address what I consider to be the biggest pain points with the Log panel.
Then at the end, suggest an alternative (wireframe/rough-draft) UI layout to try to address these pain points.
The activity Log menus are not a 1:1 mapping to the flow object
When you toggle open
$trigger
, it has$accountability
nested in to it.In reality,
$accountability
is actually a sibling key on the Flow Object.(note: Since
options
is nested in the Data Studio log panel, at a glance it seems like it exists on the flow object, though it doesn't.)On a similar note,
$last
is not provided within the logger at all. I'd guess the justification here is that$last
is not a "distinct value", but exists for convenience.... I think this would be nice to see in the Logger as an additional sanity check when configuring each operation in the flow.The activity Log menus are not a 1:1 mapping to the flow object... (Part 2)
This is quite similar to the first issue. Consider this example below.
By looking at the Log, we can't quickly identify the
key.subkey1.subkey2
that we need.Again, it feels like you should use
$trigger.accountability.user
, but we actually need to use$accountability.user
.At a glance, it feels like you should use
abc.payload.key
but we actually need to useabc.key
.I think this mismatch likely leads to a lot of confusion we've seen around accessing a desired value.
Redundant and divergent naming conventions
We use the same name for different things and different names for the same (well, very very similar) things.
This makes it harder to parse through the info and be certain of what you're looking at.
In the Data Studio's Log panel, we use
payload
to label the value appended under a trigger or operation key.In an Event Hook trigger configured to trigger on
items.create
events, the body of the post request is labeledpayload
.In a Webhook trigger configured to trigger on
POST
requests, the body is calledbody
.There may be additional overlapping names, but this was the most prominent.
JSON object wrapping not effectively handled
CleanShot.2022-10-03.at.14.31.54.mp4
We should add a scroll bar here.
$all exists on object but isn't accessible by users
Right now,
Response Body
uses $all variable...but this isn't available for end-users. which is somewhat confusing.
There's no option to delete/cleanup logs
This takes up memory and gets hard to sort through. There should be several delete options built-in:
New UI Suggestion for Logs Panel
The following wireframed layout includes the general suggestions/thoughts I have to improve the log panel.
value
under eachkey
.key:value
. It also reduces confusion between Config Options (input) and data appended to the Flow Object (output).Again, this is a wireframe, not a fully flushed out solution.
In the process of clarifying the Flow Object, several other design questions are raised:
Curious to see how others agree/disagree/tangent on my thoughts 🤠
Beta Was this translation helpful? Give feedback.
All reactions