@memberjunction/connector-sharepoint@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.

@memberjunction/connector-salesforce@1.2.0

Minor Changes

• 991a336: Fix the seed migration so mj app install succeeds — the migration now creates the connector's CredentialType before the Integration.

  These connectors define their own MJ: Credential Types row (e.g. PropFuel API, GrowthZone OAuth2, Salesforce JWT Bearer) and their Integration row references it via CredentialTypeID. The published migration seeded the Integration but never created the CredentialType, so every fresh install aborted at the migration step (which runs before any metadata sync) with:

  The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Integration_CredentialType" (SQL Server)
  function __mj.spCreateIntegration(...) — FK_Integration_CredentialType (PostgreSQL)
  

  Root cause was in the seed-migration generator: it reset the Integration/IntegrationObject/IntegrationObjectField catalog between connectors but left CredentialType rows in the generation DB, so mj sync push's SQL-logging saw the type already present and emitted no spCreateCredentialType call. Fixed the generator to also delete each connector's own CredentialType before its push, so the create is re-emitted; the existing directoryOrder (credential-type before integration) places it ahead of the Integration in the migration.

  Verified: each connector's regenerated migration applies cleanly against a real __mj schema (real FK_Integration_CredentialType + spCreate* functions) — CredentialType created, then Integration, then objects, 0 errors. Both SQL Server and PostgreSQL migrations regenerated; same migration version (in place).

  Connectors that reference a core credential type (OAuth2 Client Credentials, Azure Service Principal, API Key, OAuth2 Password Grant) are unaffected and unchanged — those types exist on every fresh instance.

  The spCreateCredentialType call is also guarded with IF NOT EXISTS (both dialects), so installing two connectors that share a credential type (Fonteva and Salesforce both use Salesforce JWT Bearer) on the same instance no longer collides — the second install skips the already-created type. Verified: Salesforce-then-Fonteva on one instance, both Integrations created, 0 errors.

@memberjunction/connector-salesforce@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.

@memberjunction/connector-rhythm-software@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.

@memberjunction/connector-propfuel@1.2.0

Minor Changes

• 991a336: Fix the seed migration so mj app install succeeds — the migration now creates the connector's CredentialType before the Integration.

  These connectors define their own MJ: Credential Types row (e.g. PropFuel API, GrowthZone OAuth2, Salesforce JWT Bearer) and their Integration row references it via CredentialTypeID. The published migration seeded the Integration but never created the CredentialType, so every fresh install aborted at the migration step (which runs before any metadata sync) with:

  The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Integration_CredentialType" (SQL Server)
  function __mj.spCreateIntegration(...) — FK_Integration_CredentialType (PostgreSQL)
  

  Root cause was in the seed-migration generator: it reset the Integration/IntegrationObject/IntegrationObjectField catalog between connectors but left CredentialType rows in the generation DB, so mj sync push's SQL-logging saw the type already present and emitted no spCreateCredentialType call. Fixed the generator to also delete each connector's own CredentialType before its push, so the create is re-emitted; the existing directoryOrder (credential-type before integration) places it ahead of the Integration in the migration.

  Verified: each connector's regenerated migration applies cleanly against a real __mj schema (real FK_Integration_CredentialType + spCreate* functions) — CredentialType created, then Integration, then objects, 0 errors. Both SQL Server and PostgreSQL migrations regenerated; same migration version (in place).

  Connectors that reference a core credential type (OAuth2 Client Credentials, Azure Service Principal, API Key, OAuth2 Password Grant) are unaffected and unchanged — those types exist on every fresh instance.

  The spCreateCredentialType call is also guarded with IF NOT EXISTS (both dialects), so installing two connectors that share a credential type (Fonteva and Salesforce both use Salesforce JWT Bearer) on the same instance no longer collides — the second install skips the already-created type. Verified: Salesforce-then-Fonteva on one instance, both Integrations created, 0 errors.

@memberjunction/connector-propfuel@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.

@memberjunction/connector-pheedloop@1.2.0

Minor Changes

• 991a336: Fix the seed migration so mj app install succeeds — the migration now creates the connector's CredentialType before the Integration.

  These connectors define their own MJ: Credential Types row (e.g. PropFuel API, GrowthZone OAuth2, Salesforce JWT Bearer) and their Integration row references it via CredentialTypeID. The published migration seeded the Integration but never created the CredentialType, so every fresh install aborted at the migration step (which runs before any metadata sync) with:

  The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Integration_CredentialType" (SQL Server)
  function __mj.spCreateIntegration(...) — FK_Integration_CredentialType (PostgreSQL)
  

  Root cause was in the seed-migration generator: it reset the Integration/IntegrationObject/IntegrationObjectField catalog between connectors but left CredentialType rows in the generation DB, so mj sync push's SQL-logging saw the type already present and emitted no spCreateCredentialType call. Fixed the generator to also delete each connector's own CredentialType before its push, so the create is re-emitted; the existing directoryOrder (credential-type before integration) places it ahead of the Integration in the migration.

  Verified: each connector's regenerated migration applies cleanly against a real __mj schema (real FK_Integration_CredentialType + spCreate* functions) — CredentialType created, then Integration, then objects, 0 errors. Both SQL Server and PostgreSQL migrations regenerated; same migration version (in place).

  Connectors that reference a core credential type (OAuth2 Client Credentials, Azure Service Principal, API Key, OAuth2 Password Grant) are unaffected and unchanged — those types exist on every fresh instance.

  The spCreateCredentialType call is also guarded with IF NOT EXISTS (both dialects), so installing two connectors that share a credential type (Fonteva and Salesforce both use Salesforce JWT Bearer) on the same instance no longer collides — the second install skips the already-created type. Verified: Salesforce-then-Fonteva on one instance, both Integrations created, 0 errors.

@memberjunction/connector-pheedloop@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.

@memberjunction/connector-path-lms@1.2.0

Minor Changes

• 991a336: Fix the seed migration so mj app install succeeds — the migration now creates the connector's CredentialType before the Integration.

  These connectors define their own MJ: Credential Types row (e.g. PropFuel API, GrowthZone OAuth2, Salesforce JWT Bearer) and their Integration row references it via CredentialTypeID. The published migration seeded the Integration but never created the CredentialType, so every fresh install aborted at the migration step (which runs before any metadata sync) with:

  The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Integration_CredentialType" (SQL Server)
  function __mj.spCreateIntegration(...) — FK_Integration_CredentialType (PostgreSQL)
  

  Root cause was in the seed-migration generator: it reset the Integration/IntegrationObject/IntegrationObjectField catalog between connectors but left CredentialType rows in the generation DB, so mj sync push's SQL-logging saw the type already present and emitted no spCreateCredentialType call. Fixed the generator to also delete each connector's own CredentialType before its push, so the create is re-emitted; the existing directoryOrder (credential-type before integration) places it ahead of the Integration in the migration.

  Verified: each connector's regenerated migration applies cleanly against a real __mj schema (real FK_Integration_CredentialType + spCreate* functions) — CredentialType created, then Integration, then objects, 0 errors. Both SQL Server and PostgreSQL migrations regenerated; same migration version (in place).

  Connectors that reference a core credential type (OAuth2 Client Credentials, Azure Service Principal, API Key, OAuth2 Password Grant) are unaffected and unchanged — those types exist on every fresh instance.

  The spCreateCredentialType call is also guarded with IF NOT EXISTS (both dialects), so installing two connectors that share a credential type (Fonteva and Salesforce both use Salesforce JWT Bearer) on the same instance no longer collides — the second install skips the already-created type. Verified: Salesforce-then-Fonteva on one instance, both Integrations created, 0 errors.

@memberjunction/connector-path-lms@1.1.0

Minor Changes

• fe75578: Fix the PostgreSQL seed migration so mj app install succeeds on PostgreSQL.

  The 1.0.0 PostgreSQL migration (migrations-pg/*.pg.sql) was generated with a stale SS→PG converter (CLI 5.36, which predates the boolean SP-argument coercion shipped in 5.40.x). It emitted the integration-catalog spCreate* calls with integer _Clear flags (p_<col>_Clear := 1) against BOOLEAN parameters. Because PostgreSQL resolves function overloads by exact argument type and has no implicit integer → boolean cast for a named argument, every such call aborted on apply with:

  ERROR: function __mj.spCreateIntegrationObject(... p_<col>_clear => integer ...) does not exist
  

  Regenerated each .pg.sql with CLI 5.43.0, which emits native := TRUE/:= FALSE. The same regeneration also corrects a second 5.36 defect: identifier-quoting (."Configuration") leaking into string literals inside seeded descriptions and Configuration JSON.

  SQL Server migrations (migrations/*.sql) are unchanged — this is a PostgreSQL-only fix.