Skip to content

Conversation

lane-wetmore
Copy link
Contributor

@lane-wetmore lane-wetmore commented May 2, 2025

Description

This PR updates the client count vertical bar charts to reflect new clients only.

  • The bars reflecting total clients have been removed and only bars representing new clients are shown.
  • The color and width of the vertical bars has been updated to reflect latest designs.
  • The timestamp of the latest update has been moved. Previously, it was located alongside each chart and now it is in the page header.
  • Copy for empty state updated for CE to reflect need for both start and end dates.
  • Removes monthly new client chart view for individual client tabs - entity/non-entity, secrets sync, acme - as the main chart per tab now represents the same data.

Ent tests: ✅

Ent with data on overview:
image

CE without both dates selected:
image

CE with data on overview:
image

CE single historical month:
image

TODO only if you're a HashiCorp employee

  • Backport Labels: If this fix needs to be backported, use the appropriate backport/ label that matches the desired release branch. Note that in the CE repo, the latest release branch will look like backport/x.x.x, but older release branches will be backport/ent/x.x.x+ent.
    • LTS: If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
  • ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
    of a public function, even if that change is in a CE file, double check that
    applying the patch for this PR to the ENT repo and running tests doesn't
    break any tests. Sometimes ENT only tests rely on public functions in CE
    files.
  • Jira: If this change has an associated Jira, it's referenced either
    in the PR description, commit message, or branch name.
  • RFC: If this change has an associated RFC, please link it in the description.
  • ENT PR: If this change has an associated ENT PR, please link it in the
    description. Also, make sure the changelog is in this PR, not in your ENT PR.

@lane-wetmore lane-wetmore requested a review from a team as a code owner May 2, 2025 22:37
@lane-wetmore lane-wetmore self-assigned this May 2, 2025
@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label May 2, 2025
@lane-wetmore lane-wetmore added ui and removed hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed labels May 2, 2025
@lane-wetmore lane-wetmore added this to the 1.20.0-rc milestone May 2, 2025
Copy link

github-actions bot commented May 2, 2025

Build Results:
All builds succeeded! ✅

Copy link

github-actions bot commented May 2, 2025

CI Results:
All Go tests succeeded! ✅

@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label May 5, 2025
@legend={{this.chartLegend}}
@upgradeData={{@upgradeData}}
@chartHeight="250"
{{! TODO SLW switching to basic from group loses the upgrade data info on the tooltip, confirm whether this is acceptable and revert if not }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious if anyone has a recommendation here - Assuming we want to keep the upgrade info shown in the tooltip, is it preferable to keep using VerticalBarGrouped which supported it even though we don't need to the grouping, or should we add support for it to VerticalBarBasic?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can make a ticket to add support for it to VerticalBarBasic, but it can happen in a follow-on PR as it's not a major priority

{{! Empty state for community without start query param }}
{{else if (and this.version.isCommunity (or (not @startTimestamp) (not @endTimestamp)))}}
{{! Empty state for community without start or end query param }}
{{! TODO SLW check this copy with design considering user cannot select current month }}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking w/ design on whether this copy should be updated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely double check me on this, but I think byMonthActivityData is obsolete now and uses of it can be replaced with byMonthNewClients (once the filter logic has moved to byMonthNewClients)

get byMonthActivityData() {
const { activity, mountPath } = this.args;
const nsPath = this.namespacePathForFilter;
if (mountPath) {
// only do client-side filtering if we have a mountPath filter set
return filterByMonthDataForMount(activity.byMonth, nsPath, mountPath);
}
return activity.byMonth;
}
get byMonthNewClients() {
return this.byMonthActivityData ? this.byMonthActivityData?.map((m) => m?.new_clients) : [];
}

Copy link
Contributor

@hellobontempo hellobontempo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great start on this! Let me know if you have any questions - happy to pair through any of the feedback 😄

/>
</:chart>

<:legend>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should probably keep this so users don't have to hover over the bars and read "new clients" via the tooltip (which isn't very accessible)

Plus this gap without it looks a little spacious
Screenshot 2025-05-12 at 3 33 01 PM

@@ -47,7 +41,6 @@
<Clients::ChartContainer
@title="Monthly new"
@description="ACME clients which interacted with Vault for the first time each month. Each bar represents the total new ACME clients for that month."
@timestamp={{@activity.responseTimestamp}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole chart should actually be deleted because I believe it's now a duplicate of the one above?

@@ -34,7 +33,6 @@
<Clients::ChartContainer
@title="Monthly new"
@description="Entity or non-entity clients which interacted with Vault for the first time during this date range. Each bar represents the total new clients for that month."
@timestamp={{@activity.responseTimestamp}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that these charts are the same, one should be deleted. It looks like a combination of the each chart descriptions would be the most accurate

@@ -48,11 +48,4 @@
{{yield to="emptyState"}}
</div>
{{/if}}

{{#if @timestamp}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job remembering this cleanup 🎉

@lane-wetmore lane-wetmore removed the request for review from claudiac-m May 13, 2025 15:10
@@ -8,8 +8,6 @@ import ActivityComponent from '../activity';
export default class ClientsAcmePageComponent extends ActivityComponent {
title = 'ACME usage';
get description() {
return `This data can be used to understand how many ACME clients have been used for the queried ${
this.isDateRange ? 'date range' : 'month'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing this removed makes me wonder if we can cleanup any of the isDateRange logic 🤔 I know CE users can still query a single month, but we might be able to clean some of this up for enterprise only views. Not for this PR, but perhaps something to make a ticket for - what do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, definitely! I'll add a cleanup ticket for that

Comment on lines +64 to +66
const data = mountPath
? filterByMonthDataForMount(activity.byMonth, nsPath, mountPath)
: activity.byMonth;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -48,11 +48,4 @@
{{yield to="emptyState"}}
</div>
{{/if}}

{{#if @timestamp}}
<div class="timestamp" data-test-chart-container-timestamp>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha! I realized why the screenshot of the updated chart has such a large space. It looks like chart-container.scss needs to be updated now that the timestamp div is gone.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think part of it is that the chart doesn't scale down well when the dev tools are open, which may be something to improve later, but even at full width that space does seem too large. I've updated the styles to make the final row smaller to remove that gapping.

Copy link
Contributor

@hellobontempo hellobontempo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Really appreciate the attention to detail. 😍

One small import nit, but mostly want to figure out why there's such a large space between the running total chart and the legend. I think updating the grid css in chart-container should address that (and cleaning up the .timestamp class while there!) 🎉

lane-wetmore and others added 2 commits May 16, 2025 10:13
Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>
@@ -20,7 +20,7 @@
.single-chart-grid {
display: grid;
grid-template-columns: 1fr 0.3fr 3.7fr;
grid-template-rows: 0.5fr 1fr 1fr 1fr 0.25fr;
grid-template-rows: 0.5fr 1fr 1fr 0.5fr 0.25fr;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be mis-remembering but I think a row here could be deleted all together since the timestamp lived in it's own row. But I trust your judgement if you think this looks fine in the app!

@lane-wetmore lane-wetmore merged commit cdbb0c4 into main May 19, 2025
33 checks passed
@lane-wetmore lane-wetmore deleted the ui/VAULT-35488-Client-Count-New-Clients-Only branch May 19, 2025 20:57
erentantekin pushed a commit that referenced this pull request May 23, 2025
* increase bar width, show new clients only, add timestamp to header, update bar color

* remove extra timestamps, switch to basic bar chart

* update docs and styling

* remove unneeded timestamp args

* show new client running totatls

* initial test updates

* update test

* clean up new client total calc into util fn

* bits of clean up and todos

* update tests

* update to avoid activity call when in CE and missing either start or end time

* update todos

* update tests

* tidying

* move new client total onto payload for easier access

* update more tests to align with copy changes and new client totals

* remove addressed TODOs

* Update comment

* add changelog entry

* revert to using total, update tests and clean up

* Update ui/app/components/clients/page/counts.hbs

Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>

* remove duplicate charts and update descriptions

* update tests after removing extra charts

* tidy

* update instances of byMonthActivityData to use byMonthNewClients and update tests

* Update ui/app/components/clients/running-total.ts

Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>

* update chart styles

---------

Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed ui
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants