mirror of
https://github.com/LukeHagar/developer.sailpoint.com.git
synced 2025-12-10 12:27:47 +00:00
Fix build errors
This commit is contained in:
@@ -40,7 +40,7 @@ The object model for plugins has also changed somewhat. This table maps the old
|
|||||||
| certificationLevel | certificationLevel |
|
| certificationLevel | certificationLevel |
|
||||||
| pluginAccessRight | rightRequired |
|
| pluginAccessRight | rightRequired |
|
||||||
|
|
||||||
Gone in 7.1 is the idea of a plugin configuration model, and a snippet model. Instead, these elements have been rolled into the 'PluginAttributes' map that appears in the 'manifest.xml' file required by each plugin. The 'fullPage' object is now a single entry in the attributes mapping, which only holds the title of the 'fullPage'. Snippets move into a 'List' entry key in the attributes map. For each snippet entry in the 'List', implementers can define a regular expression 'regexPattern' to match against, the 'rightRequired' to see the snippet, and then a list of <Scripts/> and <StyleSheets/> that determine the look and action of the snippet.
|
Gone in 7.1 is the idea of a plugin configuration model, and a snippet model. Instead, these elements have been rolled into the 'PluginAttributes' map that appears in the 'manifest.xml' file required by each plugin. The 'fullPage' object is now a single entry in the attributes mapping, which only holds the title of the 'fullPage'. Snippets move into a 'List' entry key in the attributes map. For each snippet entry in the 'List', implementers can define a regular expression 'regexPattern' to match against, the 'rightRequired' to see the snippet, and then a list of \<Scripts/> and \<StyleSheets/> that determine the look and action of the snippet.
|
||||||
|
|
||||||
The most readily apparent change in plugin definition going from 7.0 to 7.1 is the location of each setting's plugins. Previously, developers could define a URL to a settings page ('settingsPageTemplateURL') that they could completely customize. In 7.1, in order to support future portability and support, the settings page has been removed, and individual plugin settings have been internalized to the 'manifest.xm'l file. These settings are now defined in a 'Settings' list in the 'PluginAttributes' map. Each element of the list is a 'Setting', which can have the following defined:
|
The most readily apparent change in plugin definition going from 7.0 to 7.1 is the location of each setting's plugins. Previously, developers could define a URL to a settings page ('settingsPageTemplateURL') that they could completely customize. In 7.1, in order to support future portability and support, the settings page has been removed, and individual plugin settings have been internalized to the 'manifest.xm'l file. These settings are now defined in a 'Settings' list in the 'PluginAttributes' map. Each element of the list is a 'Setting', which can have the following defined:
|
||||||
|
|
||||||
|
|||||||
@@ -49,7 +49,7 @@ An annotation should have at least three parts
|
|||||||
- **Line 2** - The path or endpoint - this can be parameterized, which is useful for pulling back a single record. The earlier example uses parameterization by adding the variable within {} tags to the end of the URL and also declaring the @PathParam "appName" in the input arguments of the method signature.
|
- **Line 2** - The path or endpoint - this can be parameterized, which is useful for pulling back a single record. The earlier example uses parameterization by adding the variable within {} tags to the end of the URL and also declaring the @PathParam "appName" in the input arguments of the method signature.
|
||||||
- **Line 3** - The authorization of the method. The following values are allowed:
|
- **Line 3** - The authorization of the method. The following values are allowed:
|
||||||
- **@AllowAll** - Allows anyone to interrogate the endpoint.
|
- **@AllowAll** - Allows anyone to interrogate the endpoint.
|
||||||
- **@RequiredRight("<SPRight/>")** - Allows users with the named SPRight to access the endpoint.
|
- **@RequiredRight("\<SPRight/>")** - Allows users with the named SPRight to access the endpoint.
|
||||||
- **@SystemAdmin** - System administrator access only.
|
- **@SystemAdmin** - System administrator access only.
|
||||||
- **@Deferred** - Authorization is deferred to the method. When this option is selected, the implementer must also create an `Authorizer` class that implements the `sailpoint.authorization.Authorize`r interface. The `Authorizer` class should override the `authorize(UserContext)` method of the base `Authorizer` interface. Inside the REST resource method, the author would then call `authorize()`. Here is a simple example:
|
- **@Deferred** - Authorization is deferred to the method. When this option is selected, the implementer must also create an `Authorizer` class that implements the `sailpoint.authorization.Authorize`r interface. The `Authorizer` class should override the `authorize(UserContext)` method of the base `Authorizer` interface. Inside the REST resource method, the author would then call `authorize()`. Here is a simple example:
|
||||||
|
|
||||||
|
|||||||
@@ -100,7 +100,7 @@ When you launch the Community Toolbox, it prompts you to provide your tenant inf
|
|||||||
You must provide this tenant information to be able to log in:
|
You must provide this tenant information to be able to log in:
|
||||||
- **Tenant**: This is your organization's tenant name.
|
- **Tenant**: This is your organization's tenant name.
|
||||||
- **Domain**: This is usually 'identitynow'.
|
- **Domain**: This is usually 'identitynow'.
|
||||||
- **Base URL**: This is the API URL - it is 'https://{tenant}.{domain}.com', like 'https:acme.identitynow.com', for example.
|
- **Base URL**: This is the API URL - it is 'https://[tenant].[domain].com', like 'https:acme.identitynow.com', for example.
|
||||||
- **Tenant URL**: This is the tenant URL - it is often the same as the API URL.
|
- **Tenant URL**: This is the tenant URL - it is often the same as the API URL.
|
||||||
|
|
||||||
Once you have provided your tenant information, the Community Toolbox prompts you to log in to your tenant the same way you would from the browser. You must provide a password and possibly some additional form of authentication.
|
Once you have provided your tenant information, the Community Toolbox prompts you to log in to your tenant the same way you would from the browser. You must provide a password and possibly some additional form of authentication.
|
||||||
|
|||||||
Reference in New Issue
Block a user