diff --git a/content/documents/access-control-using-portal-teams.mdx b/content/documents/access-control-using-portal-teams.mdx index 806bae3a..2b92c9b7 100644 --- a/content/documents/access-control-using-portal-teams.mdx +++ b/content/documents/access-control-using-portal-teams.mdx @@ -10,25 +10,25 @@ tags: ["Portal"] ## What is access control -Access control in the OrderCloud Portal is the concept of managing a relationship between an Organization you administer and a Portal user or team of users. Each relationship has a set of permissions related to features in the Portal and a list of OrderCloud API roles for controlling data access. +Access control in the OrderCloud Portal is the concept of managing a relationship between a Marketplace you administer and a Portal user or team of users. Each relationship has a set of permissions related to features in the Portal and a list of OrderCloud API roles for controlling data access. -Upon choosing to invite a new Portal user or team to contribute to your Organization, you will be asked to define these relationships. Once the invitee accepts your request, they will be able to view and/or manage your Organization and the data within it, depending on their level of access. +Upon choosing to invite a new Portal user or team to contribute to your Marketplace, you will be asked to define these relationships. Once the invitee accepts your request, they will be able to view and/or manage your Marketplace and the data within it, depending on their level of access. -## Organization access controls +## Marketplace access controls
-Organization access controls -
A typical Organization access form in the OrderCloud Portal.
+Marketplace access controls +
A typical Marketplace access form in the OrderCloud Portal.
-### Organization admin +### Marketplace admin -This permission will allow managing everything in the Organization: team and user access (including their own), permissions, and the name of the Organization. +This permission will allow managing everything in the Marketplace: team and user access (including their own), permissions, and the name of the Marketplace. ->Organization administrators do **NOT** have access to transfer or delete the Organization. These actions are limited to the Organization Owner. +>Marketplace administrators do **NOT** have access to transfer or delete the Marketplace. These actions are limited to the Marketplace Owner. ### Impersonation access -These permissions are directly related to features in the API Console. Organization Administrators can control the types of OrderCloud Users that a contributing party can impersonate (act on behalf of). Without any of these turned on, the contributing party can only access the console as themselves. +These permissions are directly related to features in the API Console. Marketplace Administrators can control the types of OrderCloud Users that a contributing party can impersonate (act on behalf of). Without any of these turned on, the contributing party can only access the console as themselves. - Impersonate Seller Users - Impersonate Supplier Users @@ -41,35 +41,35 @@ These are the API Roles that a contributing party has access to when using the A ## Access inheritance -The OrderCloud Portal provides the ability to create teams. A Portal team is a group of users that share a common relationship with one or more Seller Organizations. Individual Portal users can also have their own relationship with a Seller Organization. This means that a single contributing user might inherit access from multiple sources, so how does an Organization administrator know where this access is provisioned when changes need to be made? +The OrderCloud Portal provides the ability to create teams. A Portal team is a group of users that share a common relationship with one or more Marketplaces. Individual Portal users can also have their own relationship with a Marketplace. This means that a single contributing user might inherit access from multiple sources, so how does a Marketplace administrator know where this access is provisioned when changes need to be made? -### Organization contributors +### Marketplace contributors -The contributors list is a flattened view of each Portal user that has accepted access to an Organization, whether that be through a direct user assignment, teams, or both. When viewing an individual contributor, you will see exactly which relationships that user has with your Organization, followed by the "inherited" permissions and data access. This "inherited" access is an inclusive merging of settings from all of the relationships listed at the top. +The contributors list is a flattened view of each Portal user that has accepted access to a Marketplace, whether that be through a direct user assignment, teams, or both. When viewing an individual contributor, you will see exactly which relationships that user has with your Marketplace, followed by the "inherited" permissions and data access. This "inherited" access is an inclusive merging of settings from all of the relationships listed at the top.
-Organization contributor detail view -
Individual contributor view for Example Organization. User B inherits access from a single team (Example Team) and direct user assignment.
+Marketplace contributor detail view +
Individual contributor view for Example Marketplace. User B inherits access from a single team (Example Team) and direct user assignment.
-Each inheritance listed provides a link to where you can view and manage (if you have permission) the Organization access controls for that specific relationship. +Each inheritance listed provides a link to where you can view and manage (if you have permission) the Marketplace access controls for that specific relationship. #### User Access -Direct user assignments will bring you to user access. Here you create or cancel pending user invitations and manage the users who have accepted individual access to your Organization. +Direct user assignments will bring you to user access. Here you create or cancel pending user invitations and manage the users who have accepted individual access to your Marketplace.
-Organization user access controls -
User B's direct user access view for Example Organization.
+Marketplace user access controls +
User B's direct user access view for Example Marketplace.
#### Team Access -Team assignments will bring you to team access. Here you create or cancel pending team invitations and manage the teams that have accepted access to your Organization. +Team assignments will bring you to team access. Here you create or cancel pending team invitations and manage the teams that have accepted access to your Marketplace.
-Organization team access controls -
Example Teams's access view for Example Organization.
+Marketplace team access controls +
Example Teams's access view for Example Marketplace.
## Best practices diff --git a/content/documents/api-clients.mdx b/content/documents/api-clients.mdx index 5f2adb5a..e080a05f 100644 --- a/content/documents/api-clients.mdx +++ b/content/documents/api-clients.mdx @@ -1,23 +1,23 @@ --- type: article title: Introduction to API Clients -description: OrderCloud uses the term API Clients to identify various access points to your organization's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid. +description: OrderCloud uses the term API Clients to identify various access points to your marketplace's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid. author: rwatt publishDate: 2016-06-24 updatedDate: 2018-06-25 tags: ["API Clients", "Authentication", "Integrations"] --- -OrderCloud uses the term API Clients to identify various access points to your organization's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid. +OrderCloud uses the term API Clients to identify various access points to your marketplace's data. These access points have properties that control what parties can use it, how they can gain access, and for how long that access remains valid. ## Creating API Clients -Like anything else on the OrderCloud platform, API Clients can be managed via our RESTful API. Whenever a new organization is created on OrderCloud, a default API Client is created along with a Full Access Seller user. You can use this initial context to create anything else in OrderCloud, including more API Clients. +Like anything else on the OrderCloud platform, API Clients can be managed via our RESTful API. Whenever a new marketplace is created on OrderCloud, a default API Client is created along with a Full Access Seller user. You can use this initial context to create anything else in OrderCloud, including more API Clients. ### Naming Your API Client Choosing the right name for your API Client is important. By picking something descriptive, future developers will better understand when they should be utilized. ### Defining User Access -You can control which parties in your organization can access each of your API Clients using any combination of the following three properties: +You can control which parties in your marketplace can access each of your API Clients using any combination of the following three properties: - `AllowSeller` - All Seller Users can use the API Client - `AllowAnySupplier` - Supplier Users in _any_ Supplier company can use the API Client @@ -46,9 +46,9 @@ This is where the `IsAnonBuyer` property comes in. When enabled, many of the Me Read more about Anonymous Shopping here. ### Token Durations -Once a party has the appropriate level of access to your organization - it's important to control _how long_ that access will last. This is controlled by two properties: `AccessTokenDuration` and `RefreshTokenDuration`. The most important of the two is `AccessTokenDuration` - this is how long an `access_token` acquired using a specific API Client ID will live (in minutes). +Once a party has the appropriate level of access to your marketplace - it's important to control _how long_ that access will last. This is controlled by two properties: `AccessTokenDuration` and `RefreshTokenDuration`. The most important of the two is `AccessTokenDuration` - this is how long an `access_token` acquired using a specific API Client ID will live (in minutes). -Once the primary `access_token` expires, if the API Client is configured with a _longer lasting_ `RefreshTokenDuration`, the original OAuth response will return a corresponding `refresh_token`. This can be used to acquire a fresh `access_token` and maintain user authentication until the `refresh_token` expires. Long lasting token durations are not recommended for systems with a high level of data access in your organization as shorter token durations are more secure. +Once the primary `access_token` expires, if the API Client is configured with a _longer lasting_ `RefreshTokenDuration`, the original OAuth response will return a corresponding `refresh_token`. This can be used to acquire a fresh `access_token` and maintain user authentication until the `refresh_token` expires. Long lasting token durations are not recommended for systems with a high level of data access in your marketplace as shorter token durations are more secure. ## Using Multiple API Clients In general, we encourage creating a new API Client for each system or isolated piece of functionality. This allows for quicker identification of bottlenecks in your solution, as every authenticated request will have the API Client that was used embedded in the `Authorization` header. diff --git a/content/documents/authentication.mdx b/content/documents/authentication.mdx index fed67352..d9f67b64 100644 --- a/content/documents/authentication.mdx +++ b/content/documents/authentication.mdx @@ -199,7 +199,7 @@ When logging in via `/oauth/token`, the following error codes can be returned to | `Auth.PasswordExpired` | Based on the security profile, the password is expired | Pwd Reset | | `Auth.InsecurePassword` | Password no longer meets requirements, and will need to be changed | Pwd Reset | | `Auth.InsufficientRole` | One or more of the roles requested is not allowed for this user | False | -| `Auth.SellerNotActive` | The organization is inactive not accessible to login | False | +| `Auth.SellerNotActive` | The MPO is inactive not accessible to login | False | | `Auth.UserNotActive` | User is not active, need to complete setup to activate | False | | `Auth.LockedOut` | User is locked out due to exceeding the max attempts | False | @@ -243,4 +243,4 @@ Content-Type: application/json; charset=UTF-8 ## Conclusion -As you can see there are many different ways that you can obtain an access token to _give_ someone access to your organization but what about _limiting_ access within your organization? OrderCloud has a built-in way of handling access within your organization via Security Profiles which we'll talk about next. +As you can see there are many different ways that you can obtain an access token to _give_ someone access to your marketplace but what about _limiting_ access within your marketplace? OrderCloud has a built-in way of handling access within your marketplace via Security Profiles which we'll talk about next. diff --git a/content/documents/catalog-visibility-rules.mdx b/content/documents/catalog-visibility-rules.mdx index da48a259..80d8c913 100644 --- a/content/documents/catalog-visibility-rules.mdx +++ b/content/documents/catalog-visibility-rules.mdx @@ -12,7 +12,7 @@ tags: ["Catalogs", "Categories", "Products", "Personalization"] We keep saying it: B2B is hard. Rarely is it a matter of creating a few products, giving them each one price, and opening them up for anyone to buy. There are contracts involved. Often times different buyers see different products at different prices. Sometimes different groups of users within the same buyer organization have varying levels of access to products. Sometimes these variations apply to entire categories of products. -To deal with all this complexity, OrderCloud.io makes heavy use of the concept of assignments. Allowing a buyer user to see a product typically means assigning the catalog to the buyer organization, assigning the user to some party (a user group or the entire organization), assigning that party to a category containing the product, and, finally, assigning the party to the product, which must also include a price schedule associated with that party-product relationship. +To deal with all this complexity, OrderCloud.io makes heavy use of the concept of assignments. Allowing a buyer user to see a product typically means assigning the catalog to the buyer organization, assigning the user to some party (a user group or the entire marketplace), assigning that party to a category containing the product, and, finally, assigning the party to the product, which must also include a price schedule associated with that party-product relationship. That’s a fair amount of work, and although it gives you extremely precise control over who sees what, it’s often more control than you really need, which can make catalog management overly burdensome. diff --git a/content/documents/custom-password-configuration.mdx b/content/documents/custom-password-configuration.mdx index 9f7e8291..267ef055 100644 --- a/content/documents/custom-password-configuration.mdx +++ b/content/documents/custom-password-configuration.mdx @@ -14,7 +14,7 @@ The release of the new feature will be followed by an OrderCloud-wide enforcemen ## New Minimum Password Requirements - **Beginning on June 1, 2021** OrderCloud will enforce the following minimum password requirements for all users in all applications. These new requirements were applied immediately to any organization created after March 1, 2021: + **Beginning on June 1, 2021** OrderCloud will enforce the following minimum password requirements for all users in all applications. These new requirements were applied immediately to any marketplace created after March 1, 2021: - Minimum length 10 characters - 1 uppercase character (A-Z) diff --git a/content/documents/impersonation.mdx b/content/documents/impersonation.mdx index 69f76c08..80f35038 100644 --- a/content/documents/impersonation.mdx +++ b/content/documents/impersonation.mdx @@ -10,7 +10,7 @@ tags: ["Authentication", "Impersonation Configs"] In some instances, you may want to allow a user to order on behalf of another user. We see this use case a lot in Customer Service Desk and Call Center scenarios where customers will call their orders in and the service rep places the order on the customer's behalf. This workflow preserves the reporting data, email notifications, and presents the catalog ordering rules the buyer is configured for. -The OrderCloud API supports this capability by allowing certain users to make API calls on behalf of a buyer user, which we refer to as impersonation. If you're an admin user with the `BuyerImpersonation` role you can impersonate any buyer user under your organization as long as an applicable Impersonation Config has been created. If you're a buyer user with the `BuyerImpersonation` role you can impersonate any other buyer user within the same buyer company as long as an applicable Impersonation Config has been created. +The OrderCloud API supports this capability by allowing certain users to make API calls on behalf of a buyer user, which we refer to as impersonation. If you're an admin user with the `BuyerImpersonation` role you can impersonate any buyer user under your marketplace as long as an applicable Impersonation Config has been created. If you're a buyer user with the `BuyerImpersonation` role you can impersonate any other buyer user within the same buyer company as long as an applicable Impersonation Config has been created. ## Creating an Impersonation Config diff --git a/content/documents/order-checkout-integration.mdx b/content/documents/order-checkout-integration.mdx index 5b1b3111..5bab7459 100644 --- a/content/documents/order-checkout-integration.mdx +++ b/content/documents/order-checkout-integration.mdx @@ -14,7 +14,7 @@ Shipping costs vary depending on vendor, product type, materials used in packagi Promotion discounts may only apply to one item and therefore should only affect the price of that item and not the order as a whole. -A group of users within your organization may be tax exempt and aren’t subject to regular tax laws as your other users. +A group of users within your organization may be tax exempt and aren't subject to regular tax laws as your other users. The Order Checkout Integration event was designed to make these calculations and estimates more customizable to better suit your business needs. With the integration event configured for your API Client, certain OrderCloud endpoints relative to the checkout process hook into predefined routes you expose in your hosted middleware application, allowing you more control over how the order total is calculated. Creating and calculating an order is normally broken down into a few steps: diff --git a/content/documents/product-visibility.mdx b/content/documents/product-visibility.mdx index b9b7fd16..0a5df856 100644 --- a/content/documents/product-visibility.mdx +++ b/content/documents/product-visibility.mdx @@ -1,7 +1,7 @@ --- type: article title: Product Visibility Requirements -description: You have many options to achieve product visibility, each with a unique purpose. The path you take depends on your business requirements. By the end of this guide you will be familiar enough with the available product visibility options to choose a method that works best for your organization. +description: You have many options to achieve product visibility, each with a unique purpose. The path you take depends on your business requirements. By the end of this guide you will be familiar enough with the available product visibility options to choose a method that works best for your marketplace. author: mposthumus publishDate: 2017-01-14 updatedDate: 2021-02-24 @@ -9,7 +9,7 @@ tags: ["Products", "Price Schedules", "Catalogs", "Categories"] --- ## Accessing Products -Users access products in the API through two different routes: `/products` and `/me/products`. You have many options to achieve product visibility, each with a unique purpose. The path you take depends on your business requirements. By the end of this guide you will be familiar enough with the available product visibility options to choose a method that works best for your organization. +Users access products in the API through two different routes: `/products` and `/me/products`. You have many options to achieve product visibility, each with a unique purpose. The path you take depends on your business requirements. By the end of this guide you will be familiar enough with the available product visibility options to choose a method that works best for your marketplace. In this guide we will explore product visibility in three different ways, it's a complex concept, but an important one to understand well. - [Visibility Rules Checklist](product-visibility#visibility-rules-checklist): A quick and dirty checklist to double-check visibility is set up correctly diff --git a/content/documents/products-pricing-ordering-in-marketplaces.mdx b/content/documents/products-pricing-ordering-in-marketplaces.mdx index b22fce5f..1d7aeed2 100644 --- a/content/documents/products-pricing-ordering-in-marketplaces.mdx +++ b/content/documents/products-pricing-ordering-in-marketplaces.mdx @@ -58,8 +58,8 @@ Marketplace owners can read and administer all resources within their marketplac - No need to pass any special parameter to get accurate pricing - When requesting pricing for a given Supplier the following precedence applies: - An explicit ProductAssignment owned by the Supplier - - The Supplier’s DefaultPriceSchedule (note: this may not be the `DefaultPriceScheduleID` of the product). - - The Product’s DefaultPriceSchedule + - The Supplier's DefaultPriceSchedule (note: this may not be the `DefaultPriceScheduleID` of the product). + - The Product's DefaultPriceSchedule ## New Properties **`Supplier.AllBuyersCanOrder`** diff --git a/content/documents/security-profiles.mdx b/content/documents/security-profiles.mdx index 3e3feb8d..d584c9de 100644 --- a/content/documents/security-profiles.mdx +++ b/content/documents/security-profiles.mdx @@ -1,14 +1,14 @@ --- type: article title: Understanding Security Profiles -description: Security profiles are groups of roles (permissions), each of which grant users access to specific API endpoints and functionality. This lets you lock down access to your organization at the API level which is very powerful. +description: Security profiles are groups of roles (permissions), each of which grant users access to specific API endpoints and functionality. This lets you lock down access to your marketplace at the API level which is very powerful. author: jilse publishDate: 2016-10-20 updatedDate: 2016-10-20 tags: ["Security Profiles", "Authentication", "Me"] --- -Security profiles are groups of roles (permissions), each of which grant users access to specific API endpoints and functionality. This lets you lock down access to your organization at the _API_ level which is very powerful. If a request is made by a user without sufficient roles, they will receive a 403 Forbidden response. +Security profiles are groups of roles (permissions), each of which grant users access to specific API endpoints and functionality. This lets you lock down access to your marketplace at the _API_ level which is very powerful. If a request is made by a user without sufficient roles, they will receive a 403 Forbidden response. ## Roles diff --git a/content/documents/using-webhooks.mdx b/content/documents/using-webhooks.mdx index 73cc5695..3d820e5d 100644 --- a/content/documents/using-webhooks.mdx +++ b/content/documents/using-webhooks.mdx @@ -8,7 +8,7 @@ updatedDate: 2021-04-04 tags: ["Integrations", "Webhooks"] --- -The OrderCloud API supports user-defined HTTP callbacks, known as webhooks. Webhooks are easy to register for your entire organization or on an application specific level. You can choose exactly which OrderCloud API endpoints will trigger your hook, the roles to be passed onto the configured Base URL, and any additional configuration data OrderCloud may need to authenticate into 3rd party systems. +The OrderCloud API supports user-defined HTTP callbacks, known as webhooks. Webhooks are easy to register for your entire marketplace or on an application specific level. You can choose exactly which OrderCloud API endpoints will trigger your hook, the roles to be passed onto the configured Base URL, and any additional configuration data OrderCloud may need to authenticate into 3rd party systems. Webhooks can only be triggered by OrderCloud endpoints that write to the database (POST, PUT, PATCH, DELETE). The request body sent to the OrderCloud endpoint (if any) will be passed along to the webhooks that use it.