@cccsaurora/howler-ui 2.12.0-dev.65 → 2.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -21,7 +21,5 @@ export const ViewTitle = ({ title, type, query, sort, span }) => {
21
21
  readonly: _jsx(Lock, { fontSize: "small" }),
22
22
  global: _jsx(Language, { fontSize: "small" }),
23
23
  personal: _jsx(Person, { fontSize: "small" })
24
- }[type] }), _jsx(Typography, { variant: "body1", children: t(title) })] }), _jsx(Typography, { variant: "caption", children: _jsx("code", { children: query }) }), (sort || span) && (_jsxs(Stack, { direction: "row", sx: { mt: 1 }, spacing: 1, children: [sort
25
- ?.split(',')
26
- .map(_sort => (_jsx(Chip, { size: "small", label: _sort.split(' ')[0], icon: _sort.endsWith('desc') ? _jsx(ArrowDownward, {}) : _jsx(ArrowUpward, {}) }, _sort.split(' ')[0]))), spanLabel && _jsx(Chip, { size: "small", label: spanLabel })] }))] }));
24
+ }[type] }), _jsx(Typography, { variant: "body1", children: t(title) })] }), _jsx(Typography, { variant: "caption", children: _jsx("code", { children: query }) }), (sort || span) && (_jsxs(Stack, { direction: "row", sx: { mt: 1 }, spacing: 1, children: [sort?.split(',').map(_sort => (_jsx(Chip, { size: "small", label: _sort.split(' ')[0], icon: _sort.endsWith('desc') ? _jsx(ArrowDownward, {}) : _jsx(ArrowUpward, {}) }, _sort.split(' ')[0]))), spanLabel && _jsx(Chip, { size: "small", label: spanLabel })] }))] }));
27
25
  };
@@ -1 +1 @@
1
- export default "# Hit Schema\n\nA howler hit can contain a large number of unique fields, each with a particular definition, in order to make hits across analytics mutually intelligible. Below is a table containing all the given hit fields, as well as their type and a short description of what they are used for. While the vast majority of the fields are based on the Elastic Common Schema (see [this guide on ECS](https://www.elastic.co/guide/en/ecs/8.5/index.html) for documentation), there are also custom fields depending on the plugins enabled in Howler.\n\n## Howler Fields - Best Practices\n\nIn order to allow for some consistency between various analytics, there are a number of fields with recommended (but not required) styles. These include:\n\n- `howler.analytic`: Denotes the overarching analytic that generated the hit. For example, if the name of your analytic is Bad Guy Finder, you can set this field to Bad Guy Finder. Examples of use:\n\n - Bad Guy Finder (correct)\n - BadGuyFinder (acceptable, but spaces are preferred)\n - bad.guy.finder (incorrect, don't use periods)\n - bad_guy_finder (incorrect, don't use underscores)\n - in general, you can use [this regex](https://regexr.com/7ikco) to validate your proposed analytic name\n\n- `howler.detection`: Denotes the specific algorithm or portion of the analytic that generated the hit. For example, if your analytic has three ways of detecting hits that should be looked at (Impossible Travel, Incorrect Login Information, XSS Attack Detection), then the manner in which the hit you're creating was detected should be set. Examples of use:\n - Impossible Travel (correct)\n - ImpossibleTravel (acceptable, but spaces are preferred)\n - impossible.travel (incorrect, don't use periods)\n - impossible_travel (incorrect, don't use underscores)\n"
1
+ export default "# Hit Schema\n\nA howler hit can contain a large number of unique fields, each with a particular definition, in order to make hits across analytics mutually intelligible. Below is a table containing all the given hit fields, as well as their type and a short description of what they are used for. While the vast majority of the fields are based on the Elastic Common Schema (see [this guide on ECS](https://www.elastic.co/guide/en/ecs/8.5/index.html) for documentation), there are also custom fields depending on the plugins enabled in Howler.\n\n## Howler Fields - Best Practices\n\nIn order to allow for some consistency between various analytics, there are a number of fields with recommended (but not required) styles. These include:\n\n- `howler.analytic`: Denotes the overarching analytic that generated the hit. For example, if the name of your analytic is Bad Guy Finder, you can set this field to Bad Guy Finder. Examples of use:\n - Bad Guy Finder (correct)\n - BadGuyFinder (acceptable, but spaces are preferred)\n - bad.guy.finder (incorrect, don't use periods)\n - bad_guy_finder (incorrect, don't use underscores)\n - in general, you can use [this regex](https://regexr.com/7ikco) to validate your proposed analytic name\n\n- `howler.detection`: Denotes the specific algorithm or portion of the analytic that generated the hit. For example, if your analytic has three ways of detecting hits that should be looked at (Impossible Travel, Incorrect Login Information, XSS Attack Detection), then the manner in which the hit you're creating was detected should be set. Examples of use:\n - Impossible Travel (correct)\n - ImpossibleTravel (acceptable, but spaces are preferred)\n - impossible.travel (incorrect, don't use periods)\n - impossible_travel (incorrect, don't use underscores)\n"
@@ -1 +1 @@
1
- export default "# Sch\u00e9ma du hit\n\nUn hit howler peut contenir un grand nombre de champs uniques, chacun avec une d\u00e9finition particuli\u00e8re, afin de rendre les hits mutuellement intelligibles d'une analyse \u00e0 l'autre. Vous trouverez ci-dessous un tableau contenant tous les champs de r\u00e9sultats donn\u00e9s, ainsi que leur type et une br\u00e8ve description de leur utilisation. Alors que la grande majorit\u00e9 des champs sont bas\u00e9s sur le sch\u00e9ma commun Elastic (voir [ici](https://www.elastic.co/guide/en/ecs/8.5/index.html) pour la documentation), il existe \u00e9galement des champs personnalis\u00e9s pour Howler, et aussi des champs suppl\u00e9mentaires configur\u00e9s par divers plugins Howler.\n\n## Champs Howler - Bonnes pratiques\n\nAfin d'assurer une certaine coh\u00e9rence entre les diff\u00e9rents analytiques, il existe un certain nombre de champs dont le style est recommand\u00e9 (mais pas obligatoire). Il s'agit notamment des champs suivants:\n\n- `howler.analytic` : Indique l'analyse globale qui a g\u00e9n\u00e9r\u00e9 le r\u00e9sultat. Par exemple, si le nom de votre analyse est Bad Guy Finder, vous pouvez d\u00e9finir ce champ \u00e0 Bad Guy Finder. Exemples d'utilisation :\n\n - Bad Guy Finder (correct)\n - BadGuyFinder (acceptable, mais les espaces sont pr\u00e9f\u00e9rables)\n - bad.guy.finder (incorrect, ne pas utiliser de points)\n - bad_guy_finder (incorrect, n'utilisez pas de caract\u00e8res de soulignement)\n - en g\u00e9n\u00e9ral, vous pouvez utiliser [cette regex](https://regexr.com/7ikco) pour valider le nom analytique que vous proposez\n\n- `howler.detection` : Indique l'algorithme sp\u00e9cifique ou la partie de l'analyse qui a g\u00e9n\u00e9r\u00e9 le hit. Par exemple, si votre analyse a trois fa\u00e7ons de d\u00e9tecter les hits qui devraient \u00eatre examin\u00e9s (Voyage impossible, Informations de connexion incorrectes, D\u00e9tection d'attaque XSS), alors la fa\u00e7on dont le hit que vous cr\u00e9ez a \u00e9t\u00e9 d\u00e9tect\u00e9 devrait \u00eatre d\u00e9finie. Exemples d'utilisation :\n - Impossible Travel (correct)\n - ImpossibleTravel (acceptable, mais les espaces sont pr\u00e9f\u00e9rables)\n - impossible.travel (incorrect, ne pas utiliser de points)\n - impossible_travel (incorrect, ne pas utiliser de caract\u00e8res de soulignement)\n"
1
+ export default "# Sch\u00e9ma du hit\n\nUn hit howler peut contenir un grand nombre de champs uniques, chacun avec une d\u00e9finition particuli\u00e8re, afin de rendre les hits mutuellement intelligibles d'une analyse \u00e0 l'autre. Vous trouverez ci-dessous un tableau contenant tous les champs de r\u00e9sultats donn\u00e9s, ainsi que leur type et une br\u00e8ve description de leur utilisation. Alors que la grande majorit\u00e9 des champs sont bas\u00e9s sur le sch\u00e9ma commun Elastic (voir [ici](https://www.elastic.co/guide/en/ecs/8.5/index.html) pour la documentation), il existe \u00e9galement des champs personnalis\u00e9s pour Howler, et aussi des champs suppl\u00e9mentaires configur\u00e9s par divers plugins Howler.\n\n## Champs Howler - Bonnes pratiques\n\nAfin d'assurer une certaine coh\u00e9rence entre les diff\u00e9rents analytiques, il existe un certain nombre de champs dont le style est recommand\u00e9 (mais pas obligatoire). Il s'agit notamment des champs suivants:\n\n- `howler.analytic` : Indique l'analyse globale qui a g\u00e9n\u00e9r\u00e9 le r\u00e9sultat. Par exemple, si le nom de votre analyse est Bad Guy Finder, vous pouvez d\u00e9finir ce champ \u00e0 Bad Guy Finder. Exemples d'utilisation :\n - Bad Guy Finder (correct)\n - BadGuyFinder (acceptable, mais les espaces sont pr\u00e9f\u00e9rables)\n - bad.guy.finder (incorrect, ne pas utiliser de points)\n - bad_guy_finder (incorrect, n'utilisez pas de caract\u00e8res de soulignement)\n - en g\u00e9n\u00e9ral, vous pouvez utiliser [cette regex](https://regexr.com/7ikco) pour valider le nom analytique que vous proposez\n\n- `howler.detection` : Indique l'algorithme sp\u00e9cifique ou la partie de l'analyse qui a g\u00e9n\u00e9r\u00e9 le hit. Par exemple, si votre analyse a trois fa\u00e7ons de d\u00e9tecter les hits qui devraient \u00eatre examin\u00e9s (Voyage impossible, Informations de connexion incorrectes, D\u00e9tection d'attaque XSS), alors la fa\u00e7on dont le hit que vous cr\u00e9ez a \u00e9t\u00e9 d\u00e9tect\u00e9 devrait \u00eatre d\u00e9finie. Exemples d'utilisation :\n - Impossible Travel (correct)\n - ImpossibleTravel (acceptable, mais les espaces sont pr\u00e9f\u00e9rables)\n - impossible.travel (incorrect, ne pas utiliser de points)\n - impossible_travel (incorrect, ne pas utiliser de caract\u00e8res de soulignement)\n"
package/package.json CHANGED
@@ -17,20 +17,20 @@
17
17
  "@dnd-kit/sortable": "^8.0.0",
18
18
  "@dnd-kit/utilities": "^3.2.2",
19
19
  "@emotion/react": "^11.14.0",
20
- "@emotion/styled": "^11.14.0",
21
- "@fontsource/roboto": "^5.2.5",
20
+ "@emotion/styled": "^11.14.1",
21
+ "@fontsource/roboto": "^5.2.6",
22
22
  "@microlink/react-json-view": "^1.26.2",
23
23
  "@monaco-editor/react": "^4.7.0",
24
- "@mui/icons-material": "^5.17.1",
24
+ "@mui/icons-material": "^5.18.0",
25
25
  "@mui/lab": "5.0.0-alpha.176",
26
- "@mui/material": "^5.17.1",
26
+ "@mui/material": "^5.18.0",
27
27
  "@mui/x-date-pickers": "^7.29.4",
28
28
  "ajv": "^8.17.1",
29
29
  "ajv-i18n": "^4.2.0",
30
- "axios": "^1.9.0",
30
+ "axios": "^1.10.0",
31
31
  "axios-retry": "^3.9.1",
32
32
  "borealis-ui": "0.11.0",
33
- "chart.js": "^4.4.9",
33
+ "chart.js": "^4.5.0",
34
34
  "chartjs-adapter-moment": "^1.0.1",
35
35
  "chartjs-plugin-zoom": "^2.2.0",
36
36
  "clsx": "^2.1.1",
@@ -46,7 +46,7 @@
46
46
  "json2mq": "^0.2.0",
47
47
  "lodash-es": "^4.17.21",
48
48
  "md5": "^2.3.0",
49
- "mermaid": "^11.6.0",
49
+ "mermaid": "^11.8.1",
50
50
  "moment": "^2.30.1",
51
51
  "monaco-editor": "^0.49.0",
52
52
  "notistack": "^3.0.2",
@@ -96,7 +96,7 @@
96
96
  "internal-slot": "1.0.7"
97
97
  },
98
98
  "type": "module",
99
- "version": "2.12.0-dev.65",
99
+ "version": "2.12.0",
100
100
  "exports": {
101
101
  "./i18n": "./i18n.js",
102
102
  "./index.css": "./index.css",