-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gh 1659 portlet pref rest controller #1660
base: master
Are you sure you want to change the base?
Changes from all commits
29fb699
9fa0f25
e132032
6db24b6
20c0b4b
99c6dab
0b6a889
4962b32
9ad7ca6
6a306bc
c8f5284
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -106,3 +106,47 @@ Example response: | |
} | ||
} | ||
``` | ||
### Portlet Preferences | ||
|
||
`/api/prefs/{task}` | ||
|
||
(example: `http://localhost:8080/uPortal/api/prefs/getprefs/weather` ) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. At first glance, it seems we should support I'm not sure if it makes sense to support (REST URIs should not contain verbs within them.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @drewwills I am already supporting gets and puts |
||
|
||
These endpoints provide a way for soffits and web-components to access and store custom preferences for | ||
individual soffits and web-components. There are several different endpoints for the various ways to store | ||
and retrieve these preferences. This is an overview of the general uses. See the Swagger UI documentation | ||
for specifics of each endpoint. | ||
|
||
NOTE: to use any of these endpoints the soffit/web-component must know its own fname as registered in uPortal. | ||
This is essential to the functionality of the endpoints | ||
|
||
#### Regular preferences vs default preferences | ||
|
||
To access the regular (entity) preferences of an individual soffit or web-component use the endpoints with | ||
only prefs in the name. These will return or store the preferences associated with the specific user for the | ||
specific soffit/web-component. This will return/store the same information as the internal call to the preferences | ||
for portlets per entity. | ||
|
||
NOTE: In order to protect unwanted meddling of portlet/soffit/web-component behavior, any preferences that you do not | ||
want changed must be declared as readonly when set at registration. Otherwise users can potentially override these | ||
settings for themselves. | ||
|
||
To access the default (definition) preferences of an individual soffit or web-component use the endpoints with | ||
definitionprefs in the name. These will return or store the preferences associated with the definition of the | ||
specific soffit/web-component set when registered with uPortal. This will return/store the same information as | ||
the internal call to the preferences for portlets. | ||
|
||
NOTE: These calls will be rejected if attempted by any user without administrative privileges. This prevents | ||
unauthorized meddling of default preferences since these calls can allow one to overwrite readonly preferences. | ||
|
||
#### Only calls | ||
|
||
There are two calls with only in their names. These are used to single out the preferences that are only associated | ||
with the called level without any extra. These are included because the normal retrieve calls return every preference | ||
up to the desired level, with any conflicting information overwritten by the higher level (just as the portlet calls do). | ||
If you wish to receive the preferences only associated with a specific level use these calls. | ||
|
||
NOTE: This may not return the preferences you expect. For example, any soffit calling the definitononly call will receive | ||
the `org.apereo.portal.soffit.connector.SoffitConnectorController.serviceUrl` value and any soffit data model preferences | ||
as well as other definition preferences. | ||
Also be aware, if the user has no preferences set and you call entityonly you will receive an empty response body. |
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest...
/api/v5-6/preferences/{fname}
AND/api/v5-6/preferences/{fname}/windowId
The first would be for preferences common to the entire publication record, the second for a specific instance of a publication record.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drewwills Ok, so why the windowId? most webcomponents won't have access to their own windowID since they aren't bundled into uportal and I don't know of an easy way for them to access it- unless you are referring to their layoutID, in the which case they would still need some way of accessing it if we take out the getEntity call. Also they don't need to know their own windowId, uPortal figures all of that from the call made internally anyways. Or are you saying to just put the word windowId to differentiate the two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drewwills Also, are you saying that the first would be the definition ones while the second is the entity? I'm not familiar with what you mean by a publication record.