fleet/frontend/components/MainContent/MainContent.tsx

103 lines
3.2 KiB
TypeScript
Raw Normal View History

import React, { ReactNode, useContext } from "react";
import classnames from "classnames";
import { hasLicenseExpired } from "utilities/helpers";
import { AppContext } from "context/app";
import AppleBMTermsMessage from "components/MDM/AppleBMTermsMessage";
import LicenseExpirationBanner from "components/LicenseExpirationBanner";
import ApplePNCertRenewalMessage from "components/MDM/ApplePNCertRenewalMessage";
import AppleBMRenewalMessage from "components/MDM/AppleBMRenewalMessage";
import AndroidEnterpriseDeletedMessage from "components/MDM/AndroidEnterpriseDeletedMessage";
import VppRenewalMessage from "./banners/VppRenewalMessage";
Prevent double banner on host details page (#31001) for #29451 # Details This PR does a slight refactor of the MainContent, HostDetailsBanners and HostDetailsPage components to prevent host-details-specific banner from being shown on the Host Details page if any app-wide banners are being displayed. It does this by allowing the child of a `<MainContent>` node to be a function which takes a parameter indicating whether app-wide banners are present. The HostDetailsPage uses this new functionality to suppress host details banners when that's the case. The HostDetailsBanners component is updated to remove logic that previously attempted to detect app-wide banners, using similar logic to what MainContent does to decide whether to show banners. Instead of repeating this logic in two places, HostDetailsBanners now just renders banners. # Checklist for submitter - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [X] Manual QA for all new/changed functionality I tested this by temporarily forcing an app-wide banner (by setting [this code](https://github.com/fleetdm/fleet/blob/52cd0588b678f52c8177210c4a2eed1ae90bc5e7/frontend/components/MainContent/MainContent.tsx#L61) to `if (true)`), then similarly doing the same for host banners by changing [this code](https://github.com/fleetdm/fleet/blob/89cdf9f61a64ae7f3000cad4548adbb3763197c9/frontend/pages/hosts/details/HostDetailsPage/components/HostDetailsBanners/HostDetailsBanners.tsx#L79-L85) to always run. On the main branch, this shows two banners: <img width="1142" height="186" alt="image" src="https://github.com/user-attachments/assets/30645470-d1db-476d-bb76-2b48fedcc75a" /> On this branch, only the app-wide banner is shown. Note that this was _only_ happening in the case of the disk encryption banner, since there was logic in place in HostDetailsBanners to prevent showing host banners if an app-wide banner was present. That logic was just missing from the disk encryption case, and we'd have to continue to keep that logic in sync with the login in MainContent any time we added a new host banner. This refactor DRYs out the code a bit so we don't have that concern going forward.
2025-07-23 19:38:11 +00:00
export interface IMainContentConfig {
renderedBanner: boolean;
}
interface IMainContentProps {
Prevent double banner on host details page (#31001) for #29451 # Details This PR does a slight refactor of the MainContent, HostDetailsBanners and HostDetailsPage components to prevent host-details-specific banner from being shown on the Host Details page if any app-wide banners are being displayed. It does this by allowing the child of a `<MainContent>` node to be a function which takes a parameter indicating whether app-wide banners are present. The HostDetailsPage uses this new functionality to suppress host details banners when that's the case. The HostDetailsBanners component is updated to remove logic that previously attempted to detect app-wide banners, using similar logic to what MainContent does to decide whether to show banners. Instead of repeating this logic in two places, HostDetailsBanners now just renders banners. # Checklist for submitter - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [X] Manual QA for all new/changed functionality I tested this by temporarily forcing an app-wide banner (by setting [this code](https://github.com/fleetdm/fleet/blob/52cd0588b678f52c8177210c4a2eed1ae90bc5e7/frontend/components/MainContent/MainContent.tsx#L61) to `if (true)`), then similarly doing the same for host banners by changing [this code](https://github.com/fleetdm/fleet/blob/89cdf9f61a64ae7f3000cad4548adbb3763197c9/frontend/pages/hosts/details/HostDetailsPage/components/HostDetailsBanners/HostDetailsBanners.tsx#L79-L85) to always run. On the main branch, this shows two banners: <img width="1142" height="186" alt="image" src="https://github.com/user-attachments/assets/30645470-d1db-476d-bb76-2b48fedcc75a" /> On this branch, only the app-wide banner is shown. Note that this was _only_ happening in the case of the disk encryption banner, since there was logic in place in HostDetailsBanners to prevent showing host banners if an app-wide banner was present. That logic was just missing from the disk encryption case, and we'd have to continue to keep that logic in sync with the login in MainContent any time we added a new host banner. This refactor DRYs out the code a bit so we don't have that concern going forward.
2025-07-23 19:38:11 +00:00
children: ReactNode | ((mainContentConfig: IMainContentConfig) => ReactNode);
/** An optional classname to pass to the main content component.
* This can be used to apply styles directly onto the main content div
*/
className?: string;
}
const baseClass = "main-content";
/**
* A component that controls the layout and styling of the main content region
* of the application.
*/
const MainContent = ({
children,
className,
}: IMainContentProps): JSX.Element => {
const classes = classnames(baseClass, className);
const {
config,
isPremiumTier,
isAndroidEnterpriseDeleted,
isApplePnsExpired,
isAppleBmExpired,
isVppExpired,
feat: enable multiple ABM and VPP tokens (#21693) > Related issue: #9956 # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Added/updated tests - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes - [x] If database migrations are included, checked table schema to confirm autoupdate - For database migrations: - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). - [x] Manual QA for all new/changed functionality --------- Co-authored-by: Martin Angers <martin.n.angers@gmail.com> Co-authored-by: Gabriel Hernandez <ghernandez345@gmail.com> Co-authored-by: Roberto Dip <rroperzh@gmail.com> Co-authored-by: Sarah Gillespie <73313222+gillespi314@users.noreply.github.com> Co-authored-by: Dante Catalfamo <43040593+dantecatalfamo@users.noreply.github.com> Co-authored-by: Roberto Dip <dip.jesusr@gmail.com>
2024-08-29 22:51:46 +00:00
needsAbmTermsRenewal,
willAppleBmExpire,
willApplePnsExpire,
willVppExpire,
} = useContext(AppContext);
const renderAppWideBanner = () => {
const isFleetLicenseExpired = hasLicenseExpired(
config?.license.expiration || ""
);
let banner: JSX.Element | null = null;
// the order of these checks is important. This is the priority order
// for showing banners and only one banner is shown at a time.
if (isApplePnsExpired || willApplePnsExpire) {
// APNs expiration banner will show for either premium or free tiers
// but all other banners are only for premium tiers
banner = <ApplePNCertRenewalMessage expired={isApplePnsExpired} />;
} else if (isPremiumTier) {
if (isAndroidEnterpriseDeleted) {
banner = <AndroidEnterpriseDeletedMessage />;
} else if (isAppleBmExpired || willAppleBmExpire) {
banner = <AppleBMRenewalMessage expired={isAppleBmExpired} />;
feat: enable multiple ABM and VPP tokens (#21693) > Related issue: #9956 # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Added/updated tests - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes - [x] If database migrations are included, checked table schema to confirm autoupdate - For database migrations: - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). - [x] Manual QA for all new/changed functionality --------- Co-authored-by: Martin Angers <martin.n.angers@gmail.com> Co-authored-by: Gabriel Hernandez <ghernandez345@gmail.com> Co-authored-by: Roberto Dip <rroperzh@gmail.com> Co-authored-by: Sarah Gillespie <73313222+gillespi314@users.noreply.github.com> Co-authored-by: Dante Catalfamo <43040593+dantecatalfamo@users.noreply.github.com> Co-authored-by: Roberto Dip <dip.jesusr@gmail.com>
2024-08-29 22:51:46 +00:00
} else if (needsAbmTermsRenewal) {
banner = <AppleBMTermsMessage />;
} else if (isVppExpired || willVppExpire) {
banner = <VppRenewalMessage expired={isVppExpired} />;
} else if (isFleetLicenseExpired) {
feat: enable multiple ABM and VPP tokens (#21693) > Related issue: #9956 # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Added/updated tests - [x] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes - [x] If database migrations are included, checked table schema to confirm autoupdate - For database migrations: - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). - [x] Manual QA for all new/changed functionality --------- Co-authored-by: Martin Angers <martin.n.angers@gmail.com> Co-authored-by: Gabriel Hernandez <ghernandez345@gmail.com> Co-authored-by: Roberto Dip <rroperzh@gmail.com> Co-authored-by: Sarah Gillespie <73313222+gillespi314@users.noreply.github.com> Co-authored-by: Dante Catalfamo <43040593+dantecatalfamo@users.noreply.github.com> Co-authored-by: Roberto Dip <dip.jesusr@gmail.com>
2024-08-29 22:51:46 +00:00
banner = <LicenseExpirationBanner />;
}
}
if (banner) {
return (
<div className={`${baseClass}--animation-disabled`}>
<div className={`${baseClass}__warning-banner`}>{banner}</div>
</div>
);
}
return null;
};
Prevent double banner on host details page (#31001) for #29451 # Details This PR does a slight refactor of the MainContent, HostDetailsBanners and HostDetailsPage components to prevent host-details-specific banner from being shown on the Host Details page if any app-wide banners are being displayed. It does this by allowing the child of a `<MainContent>` node to be a function which takes a parameter indicating whether app-wide banners are present. The HostDetailsPage uses this new functionality to suppress host details banners when that's the case. The HostDetailsBanners component is updated to remove logic that previously attempted to detect app-wide banners, using similar logic to what MainContent does to decide whether to show banners. Instead of repeating this logic in two places, HostDetailsBanners now just renders banners. # Checklist for submitter - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [X] Manual QA for all new/changed functionality I tested this by temporarily forcing an app-wide banner (by setting [this code](https://github.com/fleetdm/fleet/blob/52cd0588b678f52c8177210c4a2eed1ae90bc5e7/frontend/components/MainContent/MainContent.tsx#L61) to `if (true)`), then similarly doing the same for host banners by changing [this code](https://github.com/fleetdm/fleet/blob/89cdf9f61a64ae7f3000cad4548adbb3763197c9/frontend/pages/hosts/details/HostDetailsPage/components/HostDetailsBanners/HostDetailsBanners.tsx#L79-L85) to always run. On the main branch, this shows two banners: <img width="1142" height="186" alt="image" src="https://github.com/user-attachments/assets/30645470-d1db-476d-bb76-2b48fedcc75a" /> On this branch, only the app-wide banner is shown. Note that this was _only_ happening in the case of the disk encryption banner, since there was logic in place in HostDetailsBanners to prevent showing host banners if an app-wide banner was present. That logic was just missing from the disk encryption case, and we'd have to continue to keep that logic in sync with the login in MainContent any time we added a new host banner. This refactor DRYs out the code a bit so we don't have that concern going forward.
2025-07-23 19:38:11 +00:00
const appWideBanner = renderAppWideBanner();
const mainContentConfig: IMainContentConfig = {
renderedBanner: !!appWideBanner,
};
return (
<div className={classes}>
Prevent double banner on host details page (#31001) for #29451 # Details This PR does a slight refactor of the MainContent, HostDetailsBanners and HostDetailsPage components to prevent host-details-specific banner from being shown on the Host Details page if any app-wide banners are being displayed. It does this by allowing the child of a `<MainContent>` node to be a function which takes a parameter indicating whether app-wide banners are present. The HostDetailsPage uses this new functionality to suppress host details banners when that's the case. The HostDetailsBanners component is updated to remove logic that previously attempted to detect app-wide banners, using similar logic to what MainContent does to decide whether to show banners. Instead of repeating this logic in two places, HostDetailsBanners now just renders banners. # Checklist for submitter - [X] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [X] Manual QA for all new/changed functionality I tested this by temporarily forcing an app-wide banner (by setting [this code](https://github.com/fleetdm/fleet/blob/52cd0588b678f52c8177210c4a2eed1ae90bc5e7/frontend/components/MainContent/MainContent.tsx#L61) to `if (true)`), then similarly doing the same for host banners by changing [this code](https://github.com/fleetdm/fleet/blob/89cdf9f61a64ae7f3000cad4548adbb3763197c9/frontend/pages/hosts/details/HostDetailsPage/components/HostDetailsBanners/HostDetailsBanners.tsx#L79-L85) to always run. On the main branch, this shows two banners: <img width="1142" height="186" alt="image" src="https://github.com/user-attachments/assets/30645470-d1db-476d-bb76-2b48fedcc75a" /> On this branch, only the app-wide banner is shown. Note that this was _only_ happening in the case of the disk encryption banner, since there was logic in place in HostDetailsBanners to prevent showing host banners if an app-wide banner was present. That logic was just missing from the disk encryption case, and we'd have to continue to keep that logic in sync with the login in MainContent any time we added a new host banner. This refactor DRYs out the code a bit so we don't have that concern going forward.
2025-07-23 19:38:11 +00:00
{appWideBanner}
{typeof children === "function" ? children(mainContentConfig) : children}
</div>
);
};
export default MainContent;