Hi there,

I'm trying to refactor Custom Actions Conditions, and looks like I miss something. 

I want to remove 4 tables from HABTM and use regular has many through with polymorphic association. This will give us ability to implement additional conditions without adding new tables and(next step) use custom fields and simple WP's attributes as conditions.

Problem is that after migration and changing scope building to join tests are failing and I don't get whats is different as SQL queries looks legitimate, but in second variant query returns records where shouldn't.

Original HABTM SQL(result of work_package.custom_actions(user)):

SELECT <all joined fields of all tables cut> FROM "custom_actions"

LEFT OUTER JOIN "custom_actions_statuses" ON "custom_actions_statuses"."custom_action_id" = "custom_actions"."id"
LEFT OUTER JOIN "statuses" ON "statuses"."id" = "custom_actions_statuses"."status_id"
LEFT OUTER JOIN "custom_actions_roles" ON "custom_actions_roles"."custom_action_id" = "custom_actions"."id"
LEFT OUTER JOIN "roles" ON "roles"."id" = "custom_actions_roles"."role_id"
LEFT OUTER JOIN "custom_actions_types" ON "custom_actions_types"."custom_action_id" = "custom_actions"."id"
LEFT OUTER JOIN "types" ON "types"."id" = "custom_actions_types"."type_id"
LEFT OUTER JOIN "custom_actions_projects" ON "custom_actions_projects"."custom_action_id" = "custom_actions"."id"
LEFT OUTER JOIN "projects" ON "projects"."id" = "custom_actions_projects"."project_id"

WHERE ("custom_actions_statuses"."status_id" = 23 OR "custom_actions_statuses"."status_id" IS NULL)
AND ("custom_actions_roles"."role_id" = 28 OR "custom_actions_roles"."role_id" IS NULL)
AND ("custom_actions_types"."type_id" = 24 OR "custom_actions_types"."type_id" IS NULL)
AND ("custom_actions_projects"."project_id" = 24 OR "custom_actions_projects"."project_id" IS NULL)

 Migrated to has many through with new scopes generation.

SELECT "custom_actions".* FROM "custom_actions"

LEFT OUTER JOIN custom_action_conditions status_conditions ON status_conditions.conditionable_id = custom_actions.id AND status_conditions.conditionable_type = 'Status'
LEFT OUTER JOIN statuses ON statuses.id = status_conditions.conditionable_id AND status_conditions.conditionable_type = 'Status'
LEFT OUTER JOIN custom_action_conditions role_conditions ON role_conditions.conditionable_id = custom_actions.id AND role_conditions.conditionable_type = 'Role'
LEFT OUTER JOIN roles ON roles.id = role_conditions.conditionable_id AND role_conditions.conditionable_type = 'Role'
LEFT OUTER JOIN custom_action_conditions type_conditions ON type_conditions.conditionable_id = custom_actions.id AND type_conditions.conditionable_type = 'Type'
LEFT OUTER JOIN types ON types.id = type_conditions.conditionable_id AND type_conditions.conditionable_type = 'Type'
LEFT OUTER JOIN custom_action_conditions project_conditions ON project_conditions.conditionable_id = custom_actions.id AND project_conditions.conditionable_type = 'Project'
LEFT OUTER JOIN projects ON projects.id = project_conditions.conditionable_id AND project_conditions.conditionable_type = 'Project'

WHERE ("status_conditions"."conditionable_id" = 23 OR "status_conditions"."conditionable_id" IS NULL)
AND ("role_conditions"."conditionable_id" = 28 OR "role_conditions"."conditionable_id" IS NULL)
AND ("type_conditions"."conditionable_id" = 24 OR "type_conditions"."conditionable_id" IS NULL)
AND ("project_conditions"."conditionable_id" = 24 OR "project_conditions"."conditionable_id" IS NULL)

Failing specs are 

rspec ./spec/models/work_package/work_package_custom_actions_spec.rb:119 # WorkPackage custom_actions #custom_actions with a role restriction with the condition requiring a different role does not return the action
rspec ./spec/models/work_package/work_package_custom_actions_spec.rb:93 # WorkPackage custom_actions #custom_actions with a status restriction with the work package having a different status does not return the action

What i'm missing? 

Also, I have some concerns about this approach when we'll get a lot of conditions and its types in system globally. That's will lead us to megahuge join table.