PromucFlow_constructor/app/client/src/utils/AnalyticsUtil.tsx

260 lines
8.1 KiB
TypeScript
Raw Normal View History

2020-03-03 07:02:53 +00:00
// Events
import * as log from "loglevel";
import smartlookClient from "smartlook-client";
import { getAppsmithConfigs } from "@appsmith/configs";
import * as Sentry from "@sentry/react";
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com> ## Description This PR upgrades Prettier to v2 + enforces TypeScript’s [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax where applicable. It’s submitted as a separate PR so we can merge it easily. As a part of this PR, we reformat the codebase heavily: - add `import type` everywhere where it’s required, and - re-format the code to account for Prettier 2’s breaking changes: https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes This PR is submitted against `release` to make sure all new code by team members will adhere to new formatting standards, and we’ll have fewer conflicts when merging `bundle-optimizations` into `release`. (I’ll merge `release` back into `bundle-optimizations` once this PR is merged.) ### Why is this needed? This PR is needed because, for the Lodash optimization from https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3, we need to use `import type`. Otherwise, `babel-plugin-lodash` complains that `LoDashStatic` is not a lodash function. However, just using `import type` in the current codebase will give you this: <img width="962" alt="Screenshot 2023-03-08 at 17 45 59" src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png"> That’s because Prettier 1 can’t parse `import type` at all. To parse it, we need to upgrade to Prettier 2. ### Why enforce `import type`? Apart from just enabling `import type` support, this PR enforces specifying `import type` everywhere it’s needed. (Developers will get immediate TypeScript and ESLint errors when they forget to do so.) I’m doing this because I believe `import type` improves DX and makes refactorings easier. Let’s say you had a few imports like below. Can you tell which of these imports will increase the bundle size? (Tip: it’s not all of them!) ```ts // app/client/src/workers/Linting/utils.ts import { Position } from "codemirror"; import { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` It’s pretty hard, right? What about now? ```ts // app/client/src/workers/Linting/utils.ts import type { Position } from "codemirror"; import type { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` Now, it’s clear that only `lodash` will be bundled. This helps developers to see which imports are problematic, but it _also_ helps with refactorings. Now, if you want to see where `codemirror` is bundled, you can just grep for `import \{.*\} from "codemirror"` – and you won’t get any type-only imports. This also helps (some) bundlers. Upon transpiling, TypeScript erases type-only imports completely. In some environment (not ours), this makes the bundle smaller, as the bundler doesn’t need to bundle type-only imports anymore. ## Type of change - Chore (housekeeping or task changes that don't impact user perception) ## How Has This Been Tested? This was tested to not break the build. ### Test Plan > Add Testsmith test cases links that relate to this PR ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test --------- Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
import type { User } from "constants/userConstants";
import { ANONYMOUS_USERNAME } from "constants/userConstants";
import { sha256 } from "js-sha256";
chore: Splitting analytic events (#26197) ## Description Splitting analytic events as part of adding events for SCIM #### PR fixes following issue(s) Fixes [#25891](https://github.com/appsmithorg/appsmith/issues/25891) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#speedbreakers-) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#areas-of-interest-) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-08-09 09:45:01 +00:00
import type { EventName } from "@appsmith/utils/analyticsUtilTypes";
declare global {
interface Window {
// Zipy is added via script tags in index.html
zipy: {
identify: (uid: string, userInfo: Record<string, string>) => void;
anonymize: () => void;
};
}
}
function getApplicationId(location: Location) {
const pathSplit = location.pathname.split("/");
const applicationsIndex = pathSplit.findIndex(
2020-12-24 04:32:25 +00:00
(path) => path === "applications",
);
const appId = pathSplit[applicationsIndex + 1];
return appId;
}
2019-08-30 11:23:42 +00:00
class AnalyticsUtil {
2020-11-06 06:27:36 +00:00
static cachedAnonymoustId: string;
static cachedUserId: string;
static user?: User = undefined;
chore: Use rolling window in the usage pulse call and send segment anonymous id for anonymous users (#19552) ## Description We have updated the user tracking to use a rolling window. Now the session starts when the user goes to the builder or viewer for the first time and the subsequent activity tracking will be checked only after an hour. For anonymous users, we send the Segment anonymous id in the usage calls. When the telemetry is off, we still initiate the segment, get the id and then purge the analytics global object. Fixed window (in release, as of now)- if the user starts a session at 01:15 pm, we take 01:00 pm as the session start time and we will check for the next user activity at 2:00 pm. rolling window (in this PR) - if the user starts a session at 01:15 pm, we take 01:15 pm as the session start time and we will check for the next user activity at 2:15 pm. Fixes https://github.com/appsmithorg/cloud-services/issues/183 ## Type of change - New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Manual ### Test Plan ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test
2023-01-10 12:09:33 +00:00
static blockTrackEvent: boolean | undefined;
chore: Add instance id property to all analytic events (#24300) ## Description Add instance id property to all analytic events #### PR fixes following issue(s) Fixes [#24243](https://github.com/appsmithorg/appsmith/issues/24243) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Test-plan-implementation#speedbreaker-features-to-consider-for-every-change) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans/_edit#areas-of-interest) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-06-10 05:05:12 +00:00
static instanceId?: string = "";
static initializeSmartLook(id: string) {
smartlookClient.init(id);
2019-09-09 09:08:54 +00:00
}
2019-08-30 11:23:42 +00:00
static initializeSegment(key: string) {
const initPromise = new Promise<boolean>((resolve) => {
(function init(window: any) {
const analytics = (window.analytics = window.analytics || []);
if (!analytics.initialize) {
if (analytics.invoked) {
log.error("Segment snippet included twice.");
} else {
analytics.invoked = !0;
analytics.methods = [
"trackSubmit",
"trackClick",
"trackLink",
"trackForm",
"pageview",
"identify",
"reset",
"group",
"track",
"ready",
"alias",
"debug",
"page",
"once",
"off",
"on",
];
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com> ## Description This PR upgrades Prettier to v2 + enforces TypeScript’s [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax where applicable. It’s submitted as a separate PR so we can merge it easily. As a part of this PR, we reformat the codebase heavily: - add `import type` everywhere where it’s required, and - re-format the code to account for Prettier 2’s breaking changes: https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes This PR is submitted against `release` to make sure all new code by team members will adhere to new formatting standards, and we’ll have fewer conflicts when merging `bundle-optimizations` into `release`. (I’ll merge `release` back into `bundle-optimizations` once this PR is merged.) ### Why is this needed? This PR is needed because, for the Lodash optimization from https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3, we need to use `import type`. Otherwise, `babel-plugin-lodash` complains that `LoDashStatic` is not a lodash function. However, just using `import type` in the current codebase will give you this: <img width="962" alt="Screenshot 2023-03-08 at 17 45 59" src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png"> That’s because Prettier 1 can’t parse `import type` at all. To parse it, we need to upgrade to Prettier 2. ### Why enforce `import type`? Apart from just enabling `import type` support, this PR enforces specifying `import type` everywhere it’s needed. (Developers will get immediate TypeScript and ESLint errors when they forget to do so.) I’m doing this because I believe `import type` improves DX and makes refactorings easier. Let’s say you had a few imports like below. Can you tell which of these imports will increase the bundle size? (Tip: it’s not all of them!) ```ts // app/client/src/workers/Linting/utils.ts import { Position } from "codemirror"; import { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` It’s pretty hard, right? What about now? ```ts // app/client/src/workers/Linting/utils.ts import type { Position } from "codemirror"; import type { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` Now, it’s clear that only `lodash` will be bundled. This helps developers to see which imports are problematic, but it _also_ helps with refactorings. Now, if you want to see where `codemirror` is bundled, you can just grep for `import \{.*\} from "codemirror"` – and you won’t get any type-only imports. This also helps (some) bundlers. Upon transpiling, TypeScript erases type-only imports completely. In some environment (not ours), this makes the bundle smaller, as the bundler doesn’t need to bundle type-only imports anymore. ## Type of change - Chore (housekeeping or task changes that don't impact user perception) ## How Has This Been Tested? This was tested to not break the build. ### Test Plan > Add Testsmith test cases links that relate to this PR ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test --------- Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
analytics.factory = function (t: any) {
return function () {
const e = Array.prototype.slice.call(arguments); //eslint-disable-line prefer-rest-params
e.unshift(t);
analytics.push(e);
return analytics;
};
2019-09-09 09:08:54 +00:00
};
}
for (let t: any = 0; t < analytics.methods.length; t++) {
const e = analytics.methods[t];
analytics[e] = analytics.factory(e);
}
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com> ## Description This PR upgrades Prettier to v2 + enforces TypeScript’s [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax where applicable. It’s submitted as a separate PR so we can merge it easily. As a part of this PR, we reformat the codebase heavily: - add `import type` everywhere where it’s required, and - re-format the code to account for Prettier 2’s breaking changes: https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes This PR is submitted against `release` to make sure all new code by team members will adhere to new formatting standards, and we’ll have fewer conflicts when merging `bundle-optimizations` into `release`. (I’ll merge `release` back into `bundle-optimizations` once this PR is merged.) ### Why is this needed? This PR is needed because, for the Lodash optimization from https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3, we need to use `import type`. Otherwise, `babel-plugin-lodash` complains that `LoDashStatic` is not a lodash function. However, just using `import type` in the current codebase will give you this: <img width="962" alt="Screenshot 2023-03-08 at 17 45 59" src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png"> That’s because Prettier 1 can’t parse `import type` at all. To parse it, we need to upgrade to Prettier 2. ### Why enforce `import type`? Apart from just enabling `import type` support, this PR enforces specifying `import type` everywhere it’s needed. (Developers will get immediate TypeScript and ESLint errors when they forget to do so.) I’m doing this because I believe `import type` improves DX and makes refactorings easier. Let’s say you had a few imports like below. Can you tell which of these imports will increase the bundle size? (Tip: it’s not all of them!) ```ts // app/client/src/workers/Linting/utils.ts import { Position } from "codemirror"; import { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` It’s pretty hard, right? What about now? ```ts // app/client/src/workers/Linting/utils.ts import type { Position } from "codemirror"; import type { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` Now, it’s clear that only `lodash` will be bundled. This helps developers to see which imports are problematic, but it _also_ helps with refactorings. Now, if you want to see where `codemirror` is bundled, you can just grep for `import \{.*\} from "codemirror"` – and you won’t get any type-only imports. This also helps (some) bundlers. Upon transpiling, TypeScript erases type-only imports completely. In some environment (not ours), this makes the bundle smaller, as the bundler doesn’t need to bundle type-only imports anymore. ## Type of change - Chore (housekeeping or task changes that don't impact user perception) ## How Has This Been Tested? This was tested to not break the build. ### Test Plan > Add Testsmith test cases links that relate to this PR ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test --------- Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
analytics.load = function (t: any, e: any) {
const n = document.createElement("script");
n.type = "text/javascript";
n.async = !0;
// Ref: https://www.notion.so/appsmith/530051a2083040b5bcec15a46121aea3
n.src = "https://a.appsmith.com/reroute/" + t + "/main.js";
const a: any = document.getElementsByTagName("script")[0];
a.parentNode.insertBefore(n, a);
analytics._loadOptions = e;
2019-09-09 09:08:54 +00:00
};
analytics.ready(() => {
resolve(true);
});
setTimeout(() => {
resolve(false);
}, 2000);
analytics.SNIPPET_VERSION = "4.1.0";
// Ref: https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/#batching
analytics.load(key, {
integrations: {
"Segment.io": {
deliveryStrategy: {
strategy: "batching", // The delivery strategy used for sending events to Segment
config: {
size: 100, // The batch size is the threshold that forces all batched events to be sent once its reached.
timeout: 1000, // The number of milliseconds that forces all events queued for batching to be sent, regardless of the batch size, once its reached
},
},
},
},
});
if (!AnalyticsUtil.blockTrackEvent) {
analytics.page();
}
2019-09-09 09:08:54 +00:00
}
})(window);
});
return initPromise;
2019-09-09 09:08:54 +00:00
}
2019-08-30 11:23:42 +00:00
2020-10-07 11:19:56 +00:00
static logEvent(eventName: EventName, eventData: any = {}) {
chore: Use rolling window in the usage pulse call and send segment anonymous id for anonymous users (#19552) ## Description We have updated the user tracking to use a rolling window. Now the session starts when the user goes to the builder or viewer for the first time and the subsequent activity tracking will be checked only after an hour. For anonymous users, we send the Segment anonymous id in the usage calls. When the telemetry is off, we still initiate the segment, get the id and then purge the analytics global object. Fixed window (in release, as of now)- if the user starts a session at 01:15 pm, we take 01:00 pm as the session start time and we will check for the next user activity at 2:00 pm. rolling window (in this PR) - if the user starts a session at 01:15 pm, we take 01:15 pm as the session start time and we will check for the next user activity at 2:15 pm. Fixes https://github.com/appsmithorg/cloud-services/issues/183 ## Type of change - New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Manual ### Test Plan ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test
2023-01-10 12:09:33 +00:00
if (AnalyticsUtil.blockTrackEvent) {
return;
}
2019-09-09 09:08:54 +00:00
const windowDoc: any = window;
2020-03-06 04:59:24 +00:00
let finalEventData = eventData;
const userData = AnalyticsUtil.user;
chore: Add instance id property to all analytic events (#24300) ## Description Add instance id property to all analytic events #### PR fixes following issue(s) Fixes [#24243](https://github.com/appsmithorg/appsmith/issues/24243) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Test-plan-implementation#speedbreaker-features-to-consider-for-every-change) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans/_edit#areas-of-interest) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-06-10 05:05:12 +00:00
const instanceId = AnalyticsUtil.instanceId;
const appId = getApplicationId(windowDoc.location);
chore: Splitting analytic events (#26197) ## Description Splitting analytic events as part of adding events for SCIM #### PR fixes following issue(s) Fixes [#25891](https://github.com/appsmithorg/appsmith/issues/25891) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#speedbreakers-) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#areas-of-interest-) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-08-09 09:45:01 +00:00
const { appVersion, segment } = getAppsmithConfigs();
2020-03-06 04:59:24 +00:00
if (userData) {
let user: any = {};
if (segment.apiKey) {
user = {
userId: userData.username,
email: userData.email,
appId: appId,
2020-11-23 13:17:12 +00:00
source: "cloud",
};
} else {
const userId = userData.username;
if (userId !== AnalyticsUtil.cachedUserId) {
AnalyticsUtil.cachedAnonymoustId = sha256(userId);
AnalyticsUtil.cachedUserId = userId;
}
user = {
userId: AnalyticsUtil.cachedAnonymoustId,
source: "ce",
};
}
2020-03-06 04:59:24 +00:00
finalEventData = {
...eventData,
userData: user.userId === ANONYMOUS_USERNAME ? undefined : user,
2020-03-06 04:59:24 +00:00
};
}
chore: Splitting analytic events (#26197) ## Description Splitting analytic events as part of adding events for SCIM #### PR fixes following issue(s) Fixes [#25891](https://github.com/appsmithorg/appsmith/issues/25891) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#speedbreakers-) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans#areas-of-interest-) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-08-09 09:45:01 +00:00
finalEventData = { ...finalEventData, instanceId, version: appVersion.id };
2020-12-30 07:31:20 +00:00
if (windowDoc.analytics) {
2020-11-05 16:51:22 +00:00
log.debug("Event fired", eventName, finalEventData);
2020-03-06 04:59:24 +00:00
windowDoc.analytics.track(eventName, finalEventData);
2021-04-27 12:53:08 +00:00
} else {
log.debug("Event fired locally", eventName, finalEventData);
2020-03-03 07:02:53 +00:00
}
2019-09-09 09:08:54 +00:00
}
2019-08-30 11:23:42 +00:00
static identifyUser(userData: User) {
const { segment, sentry, smartLook } = getAppsmithConfigs();
2019-09-09 09:08:54 +00:00
const windowDoc: any = window;
2020-11-06 06:27:36 +00:00
const userId = userData.username;
2020-03-03 07:02:53 +00:00
if (windowDoc.analytics) {
// This flag is only set on Appsmith Cloud. In this case, we get more detailed analytics of the user
2020-11-05 06:11:29 +00:00
if (segment.apiKey) {
const userProperties = {
email: userData.email,
name: userData.name,
userId: userId,
2020-11-23 13:17:12 +00:00
source: "cloud",
};
AnalyticsUtil.user = userData;
2020-11-05 16:51:22 +00:00
log.debug("Identify User " + userId);
windowDoc.analytics.identify(userId, userProperties);
2020-11-05 16:51:22 +00:00
} else if (segment.ceKey) {
// This is a self-hosted instance. Only send data if the analytics are NOT disabled by the user
2020-11-06 06:27:36 +00:00
if (userId !== AnalyticsUtil.cachedUserId) {
AnalyticsUtil.cachedAnonymoustId = sha256(userId);
AnalyticsUtil.cachedUserId = userId;
}
2020-11-23 13:17:12 +00:00
const userProperties = {
userId: AnalyticsUtil.cachedAnonymoustId,
2020-11-23 13:17:12 +00:00
source: "ce",
};
2020-11-06 06:27:36 +00:00
log.debug(
"Identify Anonymous User " + AnalyticsUtil.cachedAnonymoustId,
);
2020-11-23 13:17:12 +00:00
windowDoc.analytics.identify(
AnalyticsUtil.cachedAnonymoustId,
userProperties,
);
}
2020-03-03 07:02:53 +00:00
}
if (sentry.enabled) {
chore: upgrade to prettier v2 + enforce import types (#21013)Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com> ## Description This PR upgrades Prettier to v2 + enforces TypeScript’s [`import type`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-and-export) syntax where applicable. It’s submitted as a separate PR so we can merge it easily. As a part of this PR, we reformat the codebase heavily: - add `import type` everywhere where it’s required, and - re-format the code to account for Prettier 2’s breaking changes: https://prettier.io/blog/2020/03/21/2.0.0.html#breaking-changes This PR is submitted against `release` to make sure all new code by team members will adhere to new formatting standards, and we’ll have fewer conflicts when merging `bundle-optimizations` into `release`. (I’ll merge `release` back into `bundle-optimizations` once this PR is merged.) ### Why is this needed? This PR is needed because, for the Lodash optimization from https://github.com/appsmithorg/appsmith/commit/7cbb12af886621256224be0c93e6a465dd710ad3, we need to use `import type`. Otherwise, `babel-plugin-lodash` complains that `LoDashStatic` is not a lodash function. However, just using `import type` in the current codebase will give you this: <img width="962" alt="Screenshot 2023-03-08 at 17 45 59" src="https://user-images.githubusercontent.com/2953267/223775744-407afa0c-e8b9-44a1-90f9-b879348da57f.png"> That’s because Prettier 1 can’t parse `import type` at all. To parse it, we need to upgrade to Prettier 2. ### Why enforce `import type`? Apart from just enabling `import type` support, this PR enforces specifying `import type` everywhere it’s needed. (Developers will get immediate TypeScript and ESLint errors when they forget to do so.) I’m doing this because I believe `import type` improves DX and makes refactorings easier. Let’s say you had a few imports like below. Can you tell which of these imports will increase the bundle size? (Tip: it’s not all of them!) ```ts // app/client/src/workers/Linting/utils.ts import { Position } from "codemirror"; import { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` It’s pretty hard, right? What about now? ```ts // app/client/src/workers/Linting/utils.ts import type { Position } from "codemirror"; import type { LintError as JSHintError, LintOptions } from "jshint"; import { get, isEmpty, isNumber, keys, last, set } from "lodash"; ``` Now, it’s clear that only `lodash` will be bundled. This helps developers to see which imports are problematic, but it _also_ helps with refactorings. Now, if you want to see where `codemirror` is bundled, you can just grep for `import \{.*\} from "codemirror"` – and you won’t get any type-only imports. This also helps (some) bundlers. Upon transpiling, TypeScript erases type-only imports completely. In some environment (not ours), this makes the bundle smaller, as the bundler doesn’t need to bundle type-only imports anymore. ## Type of change - Chore (housekeeping or task changes that don't impact user perception) ## How Has This Been Tested? This was tested to not break the build. ### Test Plan > Add Testsmith test cases links that relate to this PR ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test --------- Co-authored-by: Satish Gandham <hello@satishgandham.com> Co-authored-by: Satish Gandham <satish.iitg@gmail.com>
2023-03-16 11:41:47 +00:00
Sentry.configureScope(function (scope) {
scope.setUser({
id: userId,
username: userData.username,
email: userData.email,
});
});
}
2020-11-05 02:31:01 +00:00
if (smartLook.enabled) {
smartlookClient.identify(userId, { email: userData.email });
2020-08-21 08:13:59 +00:00
}
// If zipy was included, identify this user on the platform
if (window.zipy && userId) {
window.zipy.identify(userId, {
email: userData.email,
username: userData.username,
});
}
chore: Use rolling window in the usage pulse call and send segment anonymous id for anonymous users (#19552) ## Description We have updated the user tracking to use a rolling window. Now the session starts when the user goes to the builder or viewer for the first time and the subsequent activity tracking will be checked only after an hour. For anonymous users, we send the Segment anonymous id in the usage calls. When the telemetry is off, we still initiate the segment, get the id and then purge the analytics global object. Fixed window (in release, as of now)- if the user starts a session at 01:15 pm, we take 01:00 pm as the session start time and we will check for the next user activity at 2:00 pm. rolling window (in this PR) - if the user starts a session at 01:15 pm, we take 01:15 pm as the session start time and we will check for the next user activity at 2:15 pm. Fixes https://github.com/appsmithorg/cloud-services/issues/183 ## Type of change - New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Manual ### Test Plan ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test
2023-01-10 12:09:33 +00:00
AnalyticsUtil.blockTrackEvent = false;
2019-09-09 09:08:54 +00:00
}
chore: Add instance id property to all analytic events (#24300) ## Description Add instance id property to all analytic events #### PR fixes following issue(s) Fixes [#24243](https://github.com/appsmithorg/appsmith/issues/24243) #### Type of change - Chore (housekeeping or task changes that don't impact user perception) ## Testing #### How Has This Been Tested? - [x] Manual - [ ] Jest - [ ] Cypress ## Checklist: #### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag #### QA activity: - [ ] [Speedbreak features](https://github.com/appsmithorg/TestSmith/wiki/Test-plan-implementation#speedbreaker-features-to-consider-for-every-change) have been covered - [ ] Test plan covers all impacted features and [areas of interest](https://github.com/appsmithorg/TestSmith/wiki/Guidelines-for-test-plans/_edit#areas-of-interest) - [ ] Test plan has been peer reviewed by project stakeholders and other QA members - [ ] Manually tested functionality on DP - [ ] We had an implementation alignment call with stakeholders post QA Round 2 - [ ] Cypress test cases have been added and approved by SDET/manual QA - [ ] Added `Test Plan Approved` label after Cypress tests were reviewed - [ ] Added `Test Plan Approved` label after JUnit tests were reviewed
2023-06-10 05:05:12 +00:00
static initInstanceId(instanceId: string) {
AnalyticsUtil.instanceId = instanceId;
}
static getAnonymousId() {
const windowDoc: any = window;
const { segment } = getAppsmithConfigs();
if (windowDoc.analytics && windowDoc.analytics.user) {
return windowDoc.analytics.user().anonymousId();
} else if (segment.enabled) {
return localStorage.getItem("ajs_anonymous_id")?.replaceAll('"', "");
}
}
static reset() {
const windowDoc: any = window;
if (windowDoc.Intercom) {
windowDoc.Intercom("shutdown");
}
2020-04-15 14:19:39 +00:00
windowDoc.analytics && windowDoc.analytics.reset();
windowDoc.mixpanel && windowDoc.mixpanel.reset();
window.zipy && window.zipy.anonymize();
}
chore: Use rolling window in the usage pulse call and send segment anonymous id for anonymous users (#19552) ## Description We have updated the user tracking to use a rolling window. Now the session starts when the user goes to the builder or viewer for the first time and the subsequent activity tracking will be checked only after an hour. For anonymous users, we send the Segment anonymous id in the usage calls. When the telemetry is off, we still initiate the segment, get the id and then purge the analytics global object. Fixed window (in release, as of now)- if the user starts a session at 01:15 pm, we take 01:00 pm as the session start time and we will check for the next user activity at 2:00 pm. rolling window (in this PR) - if the user starts a session at 01:15 pm, we take 01:15 pm as the session start time and we will check for the next user activity at 2:15 pm. Fixes https://github.com/appsmithorg/cloud-services/issues/183 ## Type of change - New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Manual ### Test Plan ### Issues raised during DP testing > Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR) ## Checklist: ### Dev activity - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] PR is being merged under a feature flag ### QA activity: - [ ] Test plan has been approved by relevant developers - [ ] Test plan has been peer reviewed by QA - [ ] Cypress test cases have been added and approved by either SDET or manual QA - [ ] Organized project review call with relevant stakeholders after Round 1/2 of QA - [ ] Added Test Plan Approved label after reveiwing all Cypress test
2023-01-10 12:09:33 +00:00
static removeAnalytics() {
AnalyticsUtil.blockTrackEvent = false;
(window as any).analytics = undefined;
}
2019-08-30 11:23:42 +00:00
}
2019-09-09 09:08:54 +00:00
export default AnalyticsUtil;