diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing.mdx index 4b621923142..c2bf35e8f37 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing.mdx @@ -59,14 +59,15 @@ You can use the [usage UI](/docs/accounts/accounts-billing/general-account-setti These rules apply for organizations on our [primary user billing version](#pricing-versions). -To determine an organization's count of billable users in a calendar month, we count the users during that month who had a **billable user type** of either full platform user or core user. A user's **billable user type** is defined as the highest user type at which a user was set during a calendar month. We use UTC timezone to define the start and end of a calendar month. +Billing for billable users is done per calendar month. To determine an organization's count of billable users in a calendar month, we count the users during that month who had a **billable user type** of either full platform user or core user. A user's **billable user type** is defined as the highest user type at which a user was set during a calendar month. We use UTC timezone to define the start and end of a calendar month. -For an example of how this works in practice: If a user is set as a full platform user at any point during a calendar month, their billable user type for that month is "full platform user," and won't change, even if they downgrade later that month. This is the case even if that user is changed to a full platform user only briefly. +For an example of how this works in practice: If a user is set as a full platform user at any point during a calendar month, their billable user type for that month is `full platform user`, and won't change, even if they downgrade later in that month. This is the case even if that user is changed to a full platform user only briefly. If you're planning on adding billable users or changing your users' user type, you should keep these rules in mind. Some tips: -* If you want to add a billable user or upgrade a user, you might choose to do that at the beginning of the month. -* If you want to downgrade a user, you might choose to do that at the end of the month. +* If you want to add a billable user or upgrade a user, you will probably want to do that at the beginning of the month. +* If you want to downgrade a user, you will probably want to do that at the end of the month. +* We use UTC time to determine the start and end of a month. This means that if, for example, you were on Pacific time and you wanted to downgrade users on the last day of the month, you'd have to make those changes by 5pm Pacific time. The count of your unique users is determined by email address. If there are multiple user records in an organization that have the same email address, for billing purposes those user records would count as a single user, and that user's billable user type would be their highest user type assigned during that month. diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial.mdx index 840603fcc30..37805b10960 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/account-user-mgmt-tutorial.mdx @@ -176,6 +176,8 @@ For how to manage group access via the API, see [NerdGraph user management](/doc ## Step 6. Add users [#add-users] +Due to how we bill per calendar month, there are reasons you may want to wait until the beginning of a month to add users. For more on that, see [User billing](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing#user-count). + If you're using SCIM provisioning, you should be done at this point because your groups and users are imported from your identity provider. You can move to the [verification step](#verification). Otherwise, you'll need to add users. In the [user management UI](https://one.newrelic.com/admin-portal/organizations/users-list), you can see your users and the groups they've been assigned to. diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-capabilities.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-capabilities.mdx index 655f9e40d6f..4e0516dfe67 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-capabilities.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-capabilities.mdx @@ -26,7 +26,7 @@ There are a lot of New Relic functionalities that we **don't** make visible and Here are some other important points about role capabilities: -* **User type takes precedence.** User-type-restrictions override access given by a role's associated capabilities. For more on that, see [User access](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#user-type-groups-relation). +* **A user's user type must also allow access.** A user's access to New Relic features is governed by both user type and assigned roles. For more about that, see [User access](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#user-type-groups-relation). * **Some capabilities overlap in functionality.** This is why selecting some capability checkboxes in the UI will automatically check or uncheck other boxes. * **Capabilities don't affect querying of data.** Most capabilities apply to New Relic UI and API experiences and not to querying data. For example, if your capabilities restrict you from accessing the UI, you can still query APM data if you have access to that account. If you require more firm data boundaries for some projects or users, you can segment your data into [different accounts](/docs/accounts/accounts-billing/account-structure/add-accounts). diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx index 96504577bed..896f22426f8 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx @@ -27,16 +27,16 @@ Here we'll explain how New Relic users get access to specific capabilities and s When it comes to what New Relic features your users can access, there are two main factors: -* A user's **[user type](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type)**: For organizations on [our usage-based pricing](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing), your users' user type is a billing factor. The user type is what sets the maximum allowed capabilities a user can access. It's meant to be a long-term setting based on someone's expected New Relic duties over the next few months or years. -* A user's assigned **roles**: after a user's user type is decided, **roles** can be used to more precisely control a user's access. Roles are sets of **capabilities**, which are the granular New Relic abilities (for example, the ability to modify New Relic settings). Roles are assigned by applying them to a [user group](#groups). +* A user's **[user type](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type)**: Basic users are free, while core and full platform users are billable. What user type to make a user is a question of what an organization expects their team members to do with New Relic, and how much value they expect to get out of that work. The user type sets the maximum allowed capabilities a user can access. User type is not meant to be used for setting permissions: for that, you should use roles. +* A user's **roles**: after a user's user type is decided, **roles** can be used to more precisely control a user's access, if desired. Roles are made up of **capabilities**, which give permissions to do specific things in New Relic (for example, the ability to modify APM settings). Roles are assigned by applying them to a [user group](#groups). ### How user type and role access intersect [#user-type-role] -A New Relic user is given permission to use a New Relic feature by the combination of their a) user type, and their b) role permissions. Put another way: for a New Relic user to access something, neither the user type nor any assigned roles must restrict that. +A New Relic user is given permission to use a New Relic feature by the combination of their a) user type, and their b) role permissions. For a New Relic user to access something, their user type and the role(s) assigned to them must allow that access. -For example, let's say a basic user is assigned a role with a lot of New Relic access, like [**All product admin**](#standard-roles). Their user type (basic user) would prevent them from using many of the features that a core user or full platform user can access. In order to get more access, they'd have to upgrade to a core or full platform user. +For example, let's say a basic user has a role with wide New Relic access, like [**All product admin**](#standard-roles) (which both the default groups **User** and **Admin** have). Their user type (basic user) would prevent them from using many of the features that a core user or full platform user with that role can access. In order to get more access, the basic user would have to become a core or full platform user. -As another example: let's say a full platform user has a restrictive role assigned (like [**Read only**](#standard-roles)). A full platform user can theoretically access all of New Relic, but in this case their assigned role would restrict their access. To get more access, their assigned roles would need to be changed (for example, by assigning them to a different group, or adjusting the roles assigned to their group). +As another example: let's say a full platform user has a restrictive role assigned for a specific account (like [**Read only**](#standard-roles)). A full platform user can theoretically access all of New Relic, but in this case their assigned role for that account greatly restricts their access. To get more access, their assigned roles would need to be changed (for example, by assigning them to a different group, or adjusting the roles assigned to their group). The rest of this doc is focused on roles and groups. For more on user type, see [User type](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type). @@ -106,7 +106,7 @@ We offer several [default roles](#standard-roles), but organizations with Pro or Important points about roles: * Roles are additive: users with multiple roles assigned have the total of all permissions granted by those roles. For example, if you're in a group that gives you the `All product admin` role in an account, and in another group that gives you a `Read only` role for the same account, you have both roles, and are not restricted by the `Read only` role. -* A user's [user type](#user-type-groups-relation) overrides role-related access. +* A user's access is based on the access granted to them by their [user type](#user-type-groups-relation) and their assigned roles. * Roles govern observability platform features, while access to organization- and user-related admin settings are governed by [administration settings](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#admin-settings). To view roles and their capabilities, go to the [**Access management** UI](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks#where) and click **Roles**. diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks.mdx index bdd25c37dc0..51f8f88e382 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks.mdx @@ -94,12 +94,12 @@ Other notes for adding users: > Before changing your users' user type, we recommend you understand: -* [How to decide a user's user type](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type#choose-user-type) -* [How billable users are calculated](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing) -* [User downgrade rules](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing#user-downgrade-rules) -* If you're using [automated user management](/docs/accounts/accounts/automated-user-management/automated-user-provisioning-single-sign), you have [other options for managing user type](/docs/accounts/accounts-billing/new-relic-one-user-management/authentication-domains-saml-sso-scim-more/#user-upgrade). +* [How to decide on a user type](/docs/accounts/accounts-billing/new-relic-one-user-management/user-type#choose-user-type). +* [How users are calculated](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing), including tips on how to time adding new users, or adjusting their user type. +* [User downgrade rules](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing#user-downgrade-rules). +* Using [automated user management](/docs/accounts/accounts/automated-user-management/automated-user-provisioning-single-sign)? You have [other options for managing user type](/docs/accounts/accounts-billing/new-relic-one-user-management/authentication-domains-saml-sso-scim-more/#user-upgrade). -To change the user type of one or more users from the UI: +To change the user type of users in the UI: 1. From the [**User management** UI](#where), click the checkboxes for the users whose user type you want to edit. 2. Once you start selecting users, an option will appear for **Edit type**. diff --git a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-type.mdx b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-type.mdx index 999763fe34f..87b196729e6 100644 --- a/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-type.mdx +++ b/src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-type.mdx @@ -21,9 +21,13 @@ In this doc you'll learn how we define **user type**, what capabilities each use Want to learn about how users are calculated for billing purposes? See [New Relic pricing](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/new-relic-one-pricing-billing). If you haven't already, be sure to [sign up for a New Relic account](https://newrelic.com/signup). It's free, forever. -## What is user type? [#user-type-defined] +## What is the user type? [#user-type-defined] -A user's **user type** is what determines the maximum set of New Relic capabilities a user is entitled to access. (In addition to user type, there can be additional [role-related restrictions](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#user-type-groups-relation).) +A New Relic user's **user type** determines the maximum set of New Relic capabilities they can access. The user type is meant to be a fairly long-term setting based on a user's expected responsibilities over the next several months or longer. + +Choosing a user's user type is mainly a billing-related decision. Core users and full platform users are billable, while basic users are not. It is a matter of how much value an organization expects to get out of a team member's use of New Relic. (For details on billing, see [User billing](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing).) + +User type should **not** be used as a way to control a user's permissions. This is because New Relic will occasionally adjust the capabilities available for each user type. To control permissions, you should use [roles](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#user-type-groups-relation) to restrict acess. There are three user types: @@ -31,14 +35,8 @@ There are three user types: * **Core user**: more capabilities than a basic user. * **Full platform user**: all capabilities. -To skip to learning more about capabilities, see [Capabilities](#user-type-capabilities). To learn more about the user type concept, keep reading. - -Basic users are free, while core users and full platform users are billable. This doc is focused on what user types have access to: for details on billing, see [User billing](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing). - If you're tasked with [adding New Relic users](/docs/accounts/accounts-billing/new-relic-one-user-management/tutorial-add-new-user-groups-roles-new-relic-one-user-model/#add-users), one of the key decisions to make is what user type to make them. If you're not sure at first, you can add them as basic users and later decide which users you want to upgrade. For how to adjust user type, see [Manage user type](#manage-user-type). -The user type is meant to be a fairly long-term setting based on a user's expected responsibilities over the next several months or longer. That intention is reflected in our [billing calculations and downgrade rules](/docs/accounts/accounts-billing/new-relic-one-pricing-billing/user-count-billing). To make more frequent or more granular adjustments to what a user can access, you should [use roles](/docs/accounts/accounts-billing/new-relic-one-user-management/groups-roles-capabilities). - ## Overview of user type capabilities [#user-type-capabilities] Here's a brief summary of the capabilities of each user type: @@ -78,9 +76,7 @@ Here's a brief summary of the capabilities of each user type: -For a more detailed comparision, see the [capabilities table](#user-type-comparison-table). - -Remember that the user type overrides any [role-related permissions](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#user-type-groups-relation). +For a more detailed comparison, see the [capabilities table](#user-type-comparison-table). ## How to pick a user type [#choose-user-type] @@ -119,7 +115,7 @@ Below is a detailed comparison of capabilities by user type. Important points ab * The table comes from [our pricing page](https://newrelic.com/pricing). To find the table, visit the **User costs** heading and click **View permissions**. * Many of the features require access to our UI experiences, not to the underlying data. All users can query all data in the accounts they can access and can create and view custom charts. For instance, basic users can access data, browser monitoring data, and more, but can't access curated UI experiences. -* The user type is meant to be a long-term setting. User-type-related restrictions override role-based permissions. [Learn more about user access factors.](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#user-type-groups-relation) +* The user type is meant to be a long-term setting. Both user type and roles govern access to New Relic features. [Learn more about user access factors](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#user-type-groups-relation). For tips on why you'd choose one user type versus another, see [Decide on user type](#choose-user-type). diff --git a/src/content/docs/data-apis/manage-data/manage-data-retention.mdx b/src/content/docs/data-apis/manage-data/manage-data-retention.mdx index 06bb6645b7e..400dfae2e11 100644 --- a/src/content/docs/data-apis/manage-data/manage-data-retention.mdx +++ b/src/content/docs/data-apis/manage-data/manage-data-retention.mdx @@ -138,58 +138,7 @@ This table shows the default [namespace](/docs/glossary/glossary) retention sett - Browser - - - - 8 - - - 98 - - - - - - Browser - - - - Browser events - - - - 8 - - - 98 - - - - - - Browser - - - - Browser JS errors - - - - 8 - - - 98 - - - - - - Browser - - - - Browser page view timing + All ([learn more](#browser-namespaces)) @@ -199,7 +148,6 @@ This table shows the default [namespace](/docs/glossary/glossary) retention sett 98 - Custom events @@ -605,6 +553,21 @@ Metric retention periods are not editable. + + +All browser namespaces have the same default retention period. Here are details about the events in each browser namespace: + +* `Browser` namespace: `PageView`, `PageAction` +* `Browser events` namespace: `AjaxRequest`, `BrowserInteraction`, `BrowserTiming` +* `Browser JS errors` namespace: `JavaScriptError` +* `Browser page view timing` namespace: `PageViewTiming` + +For more about these events, see [the browser events in the data dictionary](https://docs.newrelic.com/attribute-dictionary/?dataSource=Browser+agent). + + @@ -108,8 +110,10 @@ redirects: - When [distributed tracing is enabled for browser monitoring](/docs/browser/new-relic-browser/browser-pro-features/browser-data-distributed-tracing), `Span` data is reported. + `Span` data is reported for [distributed tracing](/docs/browser/new-relic-browser/browser-pro-features/browser-data-distributed-tracing). + +For details about how long this data is retained, see [Data retention](/docs/data-apis/manage-data/manage-data-retention). \ No newline at end of file diff --git a/src/content/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/kubernetes-cluster-explorer.mdx b/src/content/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/kubernetes-cluster-explorer.mdx index 518bad12cc3..b53340f0df8 100644 --- a/src/content/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/kubernetes-cluster-explorer.mdx +++ b/src/content/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/kubernetes-cluster-explorer.mdx @@ -216,13 +216,6 @@ It's designed to help answer questions such as: * Are there any pods unable to be scheduled to a node? * Can my nodes host additional pods? - - - We recommend that you run `nri-kubernetes` version `3.2.0` or higher for the best experience. - * In version `3.2.0`, a `containerRestartDelta` metric was introduced which is used on the `Container Restarts` widget. - * In version `2.7.0`, Node status metrics were introduced which are used in the `Node Status Conditions` widget. - - The cluster **Overview** dashboard does not currently include information about Jobs or CronJobs. diff --git a/src/content/docs/new-relic-solutions/get-started/glossary.mdx b/src/content/docs/new-relic-solutions/get-started/glossary.mdx index 6c9d543aab6..20b2186cbe6 100644 --- a/src/content/docs/new-relic-solutions/get-started/glossary.mdx +++ b/src/content/docs/new-relic-solutions/get-started/glossary.mdx @@ -24,7 +24,7 @@ redirects: import accountsAccountSwitcher from 'images/accounts_screenshot-crop_account-switcher.webp' -Whether you're considering New Relic or you're already using our capabilities, this glossary of common terminology can help. And if you don't already have a New Relic account, don't hesitate to sign up at [newrelic.com/signup](https://newrelic.com/signup). It's free, forever! +Whether you're considering New Relic or you're already using our capabilities, this glossary of common terminology can help. And if you're looking to get started, see [Start using New Relic](/docs/new-relic-solutions/get-started/intro-new-relic/).