Improvements to NR1 app permissions docs #1217
Conversation
|
Should we add that basic users can't publish an application they've developed to the list of user limitations? |
| - Subscribe other users to apps they’ve created. | ||
| - Access or manage apps in the New Relic One catalog. | ||
| - Access apps in the entity explorer sidebar. | ||
| * **Basic users** can only develop New Relic One apps locally. They can’t publish or subscribe to an app, whether it's deployed in their account, available in [the public catalog](https://opensource.newrelic.com/nerdpacks/), or one they've built. |
There was a problem hiding this comment.
| * **Basic users** can only develop New Relic One apps locally. They can’t publish or subscribe to an app, whether it's deployed in their account, available in [the public catalog](https://opensource.newrelic.com/nerdpacks/), or one they've built. | |
| * **Basic users** can only develop New Relic One apps locally. They can’t publish or subscribe to an app, whether it's deployed in their account, available in the [New Relic One catalog](https://opensource.newrelic.com/nerdpacks/), or one they've built. |
There was a problem hiding this comment.
Let's use the correct product term here...
Also I'm not clear what this means?
They can’t publish or subscribe to an app, whether it's deployed in their account, available in the New Relic One catalog
What are we trying to communicate here?
There was a problem hiding this comment.
@jpvajda I'm not sure what you mean by "correct product term" sorry. Could you clarify on that.
We are trying to communicate that basic users can't actually publish a NR1 app, or subscribe an account/users/themselves to it, and that is true no matter if we're talking a NR1 app built for their NR account/org, or an app that's in our catalog (publicly available), or one they themselves have built and are trying to share in their org. Basically we're trying to clarify that this rule applies no matter the source of the app, because there has been confusion around 'well maybe this is true for NR1 app catalog but maybe I can publish it or use it if it's just in my organization', things like that.
There was a problem hiding this comment.
A lot of this terminology is confusing in general, not just in this document 😄 Technically, a user publishes a Nerdpack to the same New Relic One catalog that contains the publicly available, first-party New Relic apps. We just filter the apps that users can see. So, distinguishing between those that are "deployed in their account" and those that are "available in the New Relic One catalog" is slightly misleading.
I think something like this might clear that up:
They can't publish or subscribe to any apps or custom visualizations, including their own.
There was a problem hiding this comment.
Oh sorry, I didn't see the "catalog"-related suggested change, makes sense now.
There was a problem hiding this comment.
@zuluecho9 Thanks for updating this doc! I just have a few comments on some of the terms, which I know are confusing and hard to keep consistent 😓
| @@ -1,7 +1,7 @@ | |||
| --- | |||
| path: '/build-apps/permission-manage-apps' | |||
| duration: '' | |||
| title: 'Permissions for managing applications' | |||
| title: 'New Relic One app permissions' | |||
There was a problem hiding this comment.
There's a push to distinguish between "apps" and "visualizations", even though they use a lot of the same tools and processes (including publishing and subscribing). Since, you technically publish a Nerdpack and the permissions use the term Nerdpack, I recommend we use that term here:
Nerdpack permissions
or something like that.
| @@ -1,7 +1,7 @@ | |||
| --- | |||
| path: '/build-apps/permission-manage-apps' | |||
| duration: '' | |||
| title: 'Permissions for managing applications' | |||
| title: 'New Relic One app permissions' | |||
| template: 'GuideTemplate' | |||
| description: 'Learn about permissions for subscribing to apps' | |||
There was a problem hiding this comment.
I also recommend we update this description, as these permissions allow users to do more than subscribe.
| When you create an app, you'll likely want to share it. From New Relic One's **Apps** page, you can subscribe to apps you create, publish, and deploy, and to other publicly available apps. | ||
|
|
||
| You must have the **Nerdpack manager** role to subcribe accounts to apps. Read on to learn about permissions and versions. | ||
| Details about permissions required for creating and managing [New Relic One applications](https://developer.newrelic.com/build-apps). |
There was a problem hiding this comment.
Here again, I recommend we use the term "Nerdpacks" instead of applications (see my comment on the "title"). Also, creating the Nerdpack doesn't require the same permissions as managing it:
Permissions for managing Nerdpacks
| ### New Relic One pricing plan | ||
|
|
||
| For accounts with New Relic One pricing, there are permissions differences for basic users and full users: | ||
| There are several factors affecting your New Relic One app permissions. |
There was a problem hiding this comment.
Here, too (Nerdpack vs app):
Several factors affect your ability to manage Nerdpacks.
Echo this comment throughout the piece.
| - Subscribe other users to apps they’ve created. | ||
| - Access or manage apps in the New Relic One catalog. | ||
| - Access apps in the entity explorer sidebar. | ||
| * **Basic users** can only develop New Relic One apps locally. They can’t publish or subscribe to an app, whether it's deployed in their account, available in [the public catalog](https://opensource.newrelic.com/nerdpacks/), or one they've built. |
There was a problem hiding this comment.
A lot of this terminology is confusing in general, not just in this document 😄 Technically, a user publishes a Nerdpack to the same New Relic One catalog that contains the publicly available, first-party New Relic apps. We just filter the apps that users can see. So, distinguishing between those that are "deployed in their account" and those that are "available in the New Relic One catalog" is slightly misleading.
I think something like this might clear that up:
They can't publish or subscribe to any apps or custom visualizations, including their own.
|
|
||
| **Subscribe to publicly available applications** | ||
| * [Original user model](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/#user-models): Owners and Admins can manage New Relic One apps, as can users specifically assigned the **Nerdpack manager** add-on role. For more details about how account access works for users, see [Account access](#account-access) | ||
| * [New Relic One user model](/docs/accounts/original-accounts-billing/original-product-based-pricing/overview-changes-pricing-user-model/#user-models): the ability to publish and subscribe to apps is dependent on the "modify Nerdpacks" [capability](/docs/accounts/accounts-billing/new-relic-one-user-management/new-relic-one-user-model-understand-user-structure/#roles). The **All product admin** role has this capability, as do the default groups [**Admin** and **User**](/docs/accounts/accounts-billing/new-relic-one-user-management/new-relic-one-user-model-understand-user-structure/#groups). |
There was a problem hiding this comment.
Can't an account manager can also create a custom group/role that has this privilege?
|
|
||
| You also must have the Nerdpack manager role to subscribe the applications you create to accounts. Applications that you publish and deploy can only be subscribed to the master account that was used to publish them, or to its sub-accounts. This means you might want a New Relic admin to deploy your applications for you if they need to be available across the organization. | ||
| * If you add New Relic One apps to a master account, that access is inherited by all of its sub-accounts. |
There was a problem hiding this comment.
You've used the term "subscribe" throughout this piece. I recommend sticking with that here instead of "add".
Also, you could use active voice and more casual language:
If you subscribe a master account to an app or visualization, all of its sub-accounts can also use it
|
|
||
| You also must have the Nerdpack manager role to subscribe the applications you create to accounts. Applications that you publish and deploy can only be subscribed to the master account that was used to publish them, or to its sub-accounts. This means you might want a New Relic admin to deploy your applications for you if they need to be available across the organization. | ||
| * If you add New Relic One apps to a master account, that access is inherited by all of its sub-accounts. | ||
| * Applications that you create and deploy can only be subscribed to the master account that was used to publish them, or to its sub-accounts. This means that, if the app needs to be available across your organization, you might need a New Relic admin to deploy your app. |
There was a problem hiding this comment.
As "publishing" is the important action here, rather than "creating" and "deploying", I recommend using "publish":
Only the master account that published a Nerdpack, or the master's sub-accounts, can subscribe to that Nerdpack. So, if you want your app to be available across your organization, you may need to publish it from your organization's master account.
|
Created a new one #1230 due to technical issues and closing this one. |
This doc was pretty inaccurate. It wrongly said that pricing plan is a factor, when it's not (as far as I know, unless I've really missed something big in this area), but instead the main factor is the a) user type and b) the account/user model. So I structured it like "basic vs full user" and then went into role-related aspects, which differ by user model. To be honest, I do not know if this is the exact reality but I was trying to fill in the connections as I worked on it based on what seemed logical.
@jaesius I'm not sure who best person is to review this and make sure it's accurate, but maybe you have a recommendation. The doc was so bad I think that no matter what, this is an improvement.