[GH-ISSUE #40] Transform output not connected automatically to the root node. #1000

New Issue

GiteaMirror · 2026-05-03T01:49:54-05:00

GiteaMirror commented

2026-05-03 01:49:54 -05:00

Originally created by @FarallonWest on GitHub (Nov 11, 2025).
Original GitHub issue: https://github.com/reconurge/flowsint/issues/40

Using Maigret transform on a social profile, the output was not automatically connected to the root node.

Originally created by @FarallonWest on GitHub (Nov 11, 2025). Original GitHub issue: https://github.com/reconurge/flowsint/issues/40 Using Maigret transform on a social profile, the output was not automatically connected to the root node.

GiteaMirror closed this issue

2026-05-03 01:49:55 -05:00

GiteaMirror commented

2026-05-03 01:49:57 -05:00

@dextmorgn commented on GitHub (Nov 12, 2025):

I was able to recreate the bug, is it creating a new (duplicate) root node ?

@dextmorgn commented on GitHub (Nov 12, 2025): I was able to recreate the bug, is it creating a new (duplicate) root node ?

GiteaMirror commented

2026-05-03 01:49:58 -05:00

@FarallonWest commented on GitHub (Nov 12, 2025):

It is not creating a new duplicate node exactly. It started with social profile node (because I made one). The next offshoot was username and then the extrapolation was social profiles.

social profile A > transform using Maigret
username A> attached entities were social profiles.

For me, I would prefer the username being the top and social profiles being the connected graph nodes in hierarchy. This helps keep things cleaner, especially when you have multiple usernames. And I think this might be solved with the suggestion elsewhere about using the transform on the username vs the social profile.

@FarallonWest commented on GitHub (Nov 12, 2025): It is not creating a new duplicate node exactly. It started with social profile node (because I made one). The next offshoot was username and then the extrapolation was social profiles. - social profile A > transform using Maigret - username A> attached entities were social profiles. For me, I would prefer the username being the top and social profiles being the connected graph nodes in hierarchy. This helps keep things cleaner, especially when you have multiple usernames. And I think this might be solved with the suggestion elsewhere about using the transform on the username vs the social profile.

GiteaMirror commented

2026-05-03 01:50:00 -05:00

@drbaron1727-sudo commented on GitHub (Nov 17, 2025):

@drbaron1727-sudo commented on GitHub (Nov 17, 2025): ****

GiteaMirror commented

2026-05-03 01:50:02 -05:00

@dextmorgn commented on GitHub (Nov 18, 2025):

@FarallonWest I've made some changes about the Username and now SocialAccount (instead of SocialProfile).

Now, SocialAccount has a field Username.

For now the transform system doesn't support nested types like:

Apply username_to_social_maigret to SocialAccount.Username

But that's what I'm aiming to update in the next few days.

@FarallonWest @drbaron1727-sudo let me know if something is unclear of if you had other suggestions on this

@dextmorgn commented on GitHub (Nov 18, 2025): @FarallonWest I've made some changes about the `Username` and now `SocialAccount` (instead of `SocialProfile`). Now, `SocialAccount` has a field `Username`. For now the transform system doesn't support nested types like: > Apply `username_to_social_maigret` to `SocialAccount.Username` But that's what I'm aiming to update in the next few days. @FarallonWest @drbaron1727-sudo let me know if something is unclear of if you had other suggestions on this

GiteaMirror commented

2026-05-03 01:50:02 -05:00

@FarallonWest commented on GitHub (Nov 18, 2025):

Will do. I will have some more time to test in the coming days

@FarallonWest commented on GitHub (Nov 18, 2025): Will do. I will have some more time to test in the coming days

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/flowsint#1000