STCOR-689 STCOR-690 Support switch consortium active affiliation #1308
Conversation
| @@ -20,7 +20,15 @@ class HandlerManager extends React.Component { | |||
| constructor(props) { | |||
| super(props); | |||
| const { event, stripes, modules, data } = props; | |||
| this.components = getEventHandlers(event, stripes, modules.handler, data); | |||
| const uniqueModules = Object.values(modules) | |||
There was a problem hiding this comment.
@NikitaSedyx I think the original idea for this was to only support the handler modules. Could you explain why was this changed here?
There was a problem hiding this comment.
because non-handler modules can't handle events like LOGIN, according to https://github.com/folio-org/stripes/blob/master/doc/dev-guide.md#handlers-and-events
Stripes modules of any type can provide a handler; the handler module type is provided for the case where the handler is the only thing the module provides, i.e. there is no main-screen app and no settings.
and it's strange that we provide a handler in app or settings module, but it can't handle events
There was a problem hiding this comment.
I think each existing ui module can be also registered as a handler (in stripes config) and also introduce the actual static handler. Is that not enough?
There was a problem hiding this comment.
as an alternative, we can add handler type to our module, but it will contradict with description of handler module, additionally it will require to refactor ProfileDropdown logic to handle duplicates (actually the same logic that is applied here)
IMO following current documentation, HandlerManager should support handler of all module types, not just handlers
There was a problem hiding this comment.
it's a question of interpretation, both ways work for me :)
There was a problem hiding this comment.
so we have two use cases to use handlers: one doesn't require module as a handler, another one requires
There was a problem hiding this comment.
Thank you @NikitaSedyx. I agree with you that the docs should include the information about how to turn the existing ui-module into a handler and that the HandlerManager is intended to be used only by the hander modules. Do you think that would be sufficient?
There was a problem hiding this comment.
I believe it should be enough, I was a bit confused by 2 points
- any module can provide handler (but in fact ignored by
HandlerManager) - handler type is used for case when module provides only handler
looks like what you mentioned covers them
| const servicePointName = userData?.curServicePoint?.name; | ||
| const tenantName = userData?.tenants?.find(({ id }) => id === okapi.tenant)?.name; | ||
|
|
||
| const withLabel = Boolean(servicePointName || tenantName); |
There was a problem hiding this comment.
A better convention than with... is is... or has.... We use withFoo as a naming convention for HOCs that provide a Foo object to the component they wrap.
There was a problem hiding this comment.
agree, missed this migrating from #1307 PR
|
SonarCloud Quality Gate failed. |
Purpose
https://issues.folio.org/browse/STCOR-689
https://issues.folio.org/browse/STCOR-690
As a central tenant of a consortium, it should be able to switch the current context to manage institutional tenants. Header
X-Okapi-Tenantacts as a pointer to the current context when sending requests to the server.If a user login into the consortium central tenant, he expects to see its name in the top-right corner of the screen (in the profile dropdown trigger, above a current SP name).
Approach
updateTenantservice, which will update the current tenant, fetch resources (perms, SPs and etc.) and update session;<HandlerManager>to invoke handlers for other module types (app,settings);Preview