unleash.unleash/frontend/src/utils/unique-change-request-id.ts

import { IUiConfig } from 'interfaces/uiConfig';

export const getUniqueChangeRequestId = (
    uiConfig: Pick<IUiConfig, 'baseUriPath' | 'versionInfo'>,
    changeRequestId: number,
) =>
    `${
        uiConfig.baseUriPath || uiConfig.versionInfo?.instanceId
    }#${changeRequestId}`;
feat: add CR id to plausible events (#6035) Added conflict count to CR metrics and CR id. Something to think about: There was idea that we can aggregate this data based on CR id, but CR id is just a number from 0 to x. So it will not be unique across instances. --------- Co-authored-by: Thomas Heartman <thomas@getunleash.io> 2024-01-30 09:38:39 +01:00			`import { IUiConfig } from 'interfaces/uiConfig';`

			`export const getUniqueChangeRequestId = (`
			`uiConfig: Pick<IUiConfig, 'baseUriPath' \| 'versionInfo'>,`
			`changeRequestId: number,`
chore: add metrics for conflict creation detection (#6022) This PR adds a 'change-request-conflict-created' event whenever someone save a strategy update for a strategy that's used in either pending or scheduled change requests. Data for pending change requests will only be sent if change requests are enabled. Data for scheduled change requests will be sent regardless. Getting this data is somewhat involved, so I've extracted as much of the logic into a separate file as possible. The event re-uses the existing `change_request` metric and sends the following data for each change request that we discover conflicts on: ```ts { state: ChangeRequestState, changeRequest: string, // <unleash identifier>#<change request id> action: 'edit-strategy', eventType: 'conflict-created' } ``` There's only one action for this for now, but we could expand this event to things such as strategy deletion, feature archival, in the future. That said, I'd be happy to take it out. ## Discussion points ### Has the strategy actually been updated? This does not check whether a strategy has actually changed before emitting the event, only that you save your strategy changes. This assumes that most people will simply close the modal by clicking/tapping outside it or using the escape key instead of pressing save. However, it will likely lead to some false positives. If we think that is an issue, I would suggest adding a check that something in the strategy has actually changed in a follow-up PR. 2024-01-31 10:56:56 +01:00			`) =>`
			`${
feat: add CR id to plausible events (#6035) Added conflict count to CR metrics and CR id. Something to think about: There was idea that we can aggregate this data based on CR id, but CR id is just a number from 0 to x. So it will not be unique across instances. --------- Co-authored-by: Thomas Heartman <thomas@getunleash.io> 2024-01-30 09:38:39 +01:00			`uiConfig.baseUriPath \|\| uiConfig.versionInfo?.instanceId`
chore: add metrics for conflict creation detection (#6022) This PR adds a 'change-request-conflict-created' event whenever someone save a strategy update for a strategy that's used in either pending or scheduled change requests. Data for pending change requests will only be sent if change requests are enabled. Data for scheduled change requests will be sent regardless. Getting this data is somewhat involved, so I've extracted as much of the logic into a separate file as possible. The event re-uses the existing `change_request` metric and sends the following data for each change request that we discover conflicts on: ```ts { state: ChangeRequestState, changeRequest: string, // <unleash identifier>#<change request id> action: 'edit-strategy', eventType: 'conflict-created' } ``` There's only one action for this for now, but we could expand this event to things such as strategy deletion, feature archival, in the future. That said, I'd be happy to take it out. ## Discussion points ### Has the strategy actually been updated? This does not check whether a strategy has actually changed before emitting the event, only that you save your strategy changes. This assumes that most people will simply close the modal by clicking/tapping outside it or using the escape key instead of pressing save. However, it will likely lead to some false positives. If we think that is an issue, I would suggest adding a check that something in the strategy has actually changed in a follow-up PR. 2024-01-31 10:56:56 +01:00			}#${changeRequestId}`;