Hi GD team, we are experiencing a strange issue with one of our attributes "Deactivated" (true, false), in the "Users" table, across workspaces. The data is correctly showing in our Redshift instance but when using the attribute in the analytical designer, only partial data is returned (even in a table visualisation with no metrics applied). In particular, when using it as a filter, the "False" option is the only one appearing despite having deactivated = true users in Redshift. Could you please help us troubleshoot this issue? [CC @Rajat]

Hi Raffella, I've checked the attribute and if you select "Show missing values" option, the "true" value appears in the insight. This makes me believe that null values are being explicitly excluded, i.e, there are currently no users tied to the missing value in your DB. Could you please check on your side? You can also an insight with this attribute and change the "/edit" in the URL to "/debug", this will give you a zip file that contains among other files, the SQL query we use against your DB, it may be useful to troubleshoot further. Let me know how it goes!

Hi @Moises Morales, we have verified that we do have deactivated users in the database. I'll do the steps you suggest, thanks

I've narrow the issue down at how the "Users" dataset is connected to the group_users tables. I've created a simple insight with only the attributes "First name" and "Deactivated" on both workspaces "examplecompanya" and "GD Support Test". The resulting query in your workspace is:

"a_label_users_first_name_examplecompanya_ad4d8af28c176c" AS "a_label_users_first_name_examplecompanya_47481990ba9b43", "a_label_users_deactivated_examplecompanya_0c7d1a356fce43" AS "a_label_users_deactivated_examplecompanya_20dfbc5d517d00", "m_30d3583f0da6ba600378ab9e912ec9a8" AS "m_1"
FROM (SELECT "users"."deactivated" AS "a_label_users_deactivated_examplecompanya_0c7d1a356fce43", "users"."first_name" AS "a_label_users_first_name_examplecompanya_ad4d8af28c176c", SUM(1) AS "m_30d3583f0da6ba600378ab9e912ec9a8", TRUE AS "def_m_30d3583f0da6ba600378ab9e912ec9a8"
FROM "examplecompanya"."group_users"
INNER JOIN "examplecompanya"."users" ON "group_users"."user_id" = "users"."id"
GROUP BY "users"."deactivated", "users"."first_name") AS "t1"
WHERE "t1"."def_m_30d3583f0da6ba600378ab9e912ec9a8";

The resulting query in my workspace is:

"a_label_users_first_name_ecba7319c43240d1bf3620_fb4fa2bbf7c8c7" AS "a_label_users_first_name_ecba7319c43240d1bf3620_e722f8906db4be", "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_80551a74519b00" AS "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_58dbf30a94b1f6", "m_e10a7b576509b938b8ce9f20ce15cf0a" AS "m_1"
FROM (SELECT "deactivated" AS "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_80551a74519b00", "first_name" AS "a_label_users_first_name_ecba7319c43240d1bf3620_fb4fa2bbf7c8c7", SUM(1) AS "m_e10a7b576509b938b8ce9f20ce15cf0a", TRUE AS "def_m_e10a7b576509b938b8ce9f20ce15cf0a"
FROM "examplecompanya"."users"
GROUP BY "deactivated", "first_name") AS "t1"
WHERE "def_m_e10a7b576509b938b8ce9f20ce15cf0a";

Query 1 filters out users who are not present in the

group_users

table, due to the

INNER JOIN

. If there are deactivated users who are not associated with any group, they will: • Not show up in Query 1 (because the inner join filters them out) • Still appear in Query 2 (because it pulls directly from

users

) Testing this further, I modified the LDM in my workspace, and included the group_users table (see screenshot). This time with 1:N connections and the values are now appearing (see screenshot). New query:

SELECT "a_label_users_first_name_ecba7319c43240d1bf3620_fb4fa2bbf7c8c7" AS "a_label_users_first_name_ecba7319c43240d1bf3620_e722f8906db4be", "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_80551a74519b00" AS "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_58dbf30a94b1f6", "m_476a2328a398bbcff95b8b3405d6b451" AS "m_1"
FROM (SELECT "deactivated" AS "a_label_deactivated_ecba7319c43240d1bf3620e9ff4_80551a74519b00", "first_name" AS "a_label_users_first_name_ecba7319c43240d1bf3620_fb4fa2bbf7c8c7", SUM(1) AS "m_476a2328a398bbcff95b8b3405d6b451", TRUE AS "def_m_476a2328a398bbcff95b8b3405d6b451"
FROM "examplecompanya"."users"
GROUP BY "deactivated", "first_name") AS "t1"
WHERE "def_m_476a2328a398bbcff95b8b3405d6b451";

Could you please review the connections for the "Users" dataset in the "examplecompanya" and check whether it's needed to use M:N?

I've had some further discussions internally and we are not sure: • why is the group_users table affecting the results of a visualisation where Group or Group users attributes are not included as data points nor filters? • logically the relationship between these tables is M:N so we have some concerns in changing it to 1:N Could you explain further why this is happening?

To be honest, I am not sure why that'd be the case. Let me consult this internally to get back to you with precise details.

Thank you!

Hi @Raffaella Gozzini, Thank you for your patience. I've confirmed internally that this is indeed a bug, and I've submitted an internal ticket to address the issue related to joined tables when using M:N connections. In the meantime, aside from temporarily changing the connection type to 1:N, I recommend adding a metric to the insight, such as a simple count of an attribute which can help surface the values tied to

"true"

. This will force those attribute elements to appear in the insight. I’ve shared a test report demonstrating this behavior in your DM. Additionally, you may want to ensure that the IDs in the group_users table are associated with the

"true"

values. This can prevent those records from being filtered out by the INNER JOIN.

Hi Moises, can I please check the timeline for the resolution of the bug?

Hi Raffaella, our apologies for the radio silence. At this time I do not have any updates from our engineers, but I will make sure to provide you with one as soon as it becomes available.