Support for multiple HumHub Sites

[luke-]

No description provided.

[marc-farre]

Maybe, in a first time, we could save the previously URLs entered in the form, and show them as a suggestion to avoid having to type the hole URL each time we switch instance?

And if we can go back to the instance URL form without login out, we could switch instance quite easily.

Of course, it's not perfect, mainly for notifications, but if it's simple to develop it can help the time beeing.

[PrimozRatej]

Hey @marc-farre, as you suggested, I've prepared a quick demo.

Users can switch between instances using a dropdown list in the TextFormField. When they are connected to an instance, a swipe gesture on the WebView will reveal a back button for quick navigation back to the opener. Reconnecting to logged-in instances is instantaneous (current session inside WebView). Push notifications are configured per instance, so there's no problem here, and the redirect should continue to work. My concern is only how we can indicate to users that this exists, considering the hidden nature of the back button.

Screen.Recording.2023-11-11.at.18.04.10.mov

@luke- any thoughts?

[marc-farre]

@PrimozRatej Thanks! That's awesome! Maybe it will solve #139 ?

Perhaps we could add an entry in the account menu, next to the "Logout" entry, called something like "Return to form URL"?
Of curse, this entry will only be shown in the mobile app (we should have a way in PHP to know if Humhub is currently executed in a browser or the mobile app).

Another idea: adding a "Clear" button on the URL form to quickly remove the current URL and access to the URLs dropdown list?

[luke-]

@marc-farre I like the idea of offering an additional menu item "Back to app" or similar when using the app. We can recognize and display this.

But then we have to somehow collect currently logged in HumHub instances and offer a logout (clear) option.

[PrimozRatej]

Hey @luke - we could use the JS channels for this and a custom app header, as you mentioned, and the logic will stay on the web side, I like the idea here.

Regarding saving currently logged-in instances, I don't think that would be necessary. Instead, we can simply save the instances that the user has ever connected to, not necessarily logged in.

If the issue you see involves push notifications (those will be sent to the user if the user hasn't logged out of a particular instance), when the user clicks on a specific push notification, they will be redirected to that instance, and then they can log out.

We can save the connected instances on the mobile device itself in local storage.

[luke-]

@PrimozRatej Do I understand correctly that we only save the instances that have ever been entered?

But the user is only logged in to one installation at a time and should therefore only receive push notifications from this one.

Later, we can expand the feature to allow multiple "Logged In" instances in parallel, including push notifications.

[marc-farre]

Users can switch between instances using a dropdown list

@PrimozRatej Do you plan to release this new feature? It would be very useful! Thanks!

[luke-]

@marc-farre We should definitely get push notifications for one site to work reliably first. Before we start with multi-site support :-)

[PrimozRatej]

Hey @marc-farre, @luke-, do you think now is the time to support this feature?

[marc-farre]

@PrimozRatej I would say we must focus on:

• iOs app
• custom branded app
• reliability of the application (testing)

@luke- ?

[luke-]

@marc-farre @PrimozRatej

I think that with multi HumHub support, we have a clear argument in favour of apple app approval.

Here is a mockup masterpiece of how I would see this feature.

• Maybe we can also add a count of notifications

What you think? Should we focus on this topic? (After Branded Apps.)

[marc-farre]

If it helps for the Apple store and it's not too much work developing it, then yes of course, it would be great to have.
But I don't know if it's a big value compared to the browser navigation in the eyes of Apple (it's similar to multiple tabs).

For the UX experience, I feel like it's not intuitive to switch from an instance to another.
I think we need somewhere a dropdown accessible when browsing HumHub.

[luke-]

If it helps for the Apple store and it's not too much work developing it, then yes of course, it would be great to have. But I don't know if it's a big value compared to the browser navigation in the eyes of Apple (it's similar to multiple tabs).

Perhaps we can find another feature that is quicker and easier to implement.
The multi-instance mode is not that easy to implement.

For the UX experience, I feel like it's not intuitive to switch from an instance to another. I think we need somewhere a dropdown accessible when browsing HumHub.

• If multiple instances are added to the app, the "Instance selection" should always be displayed first at startup.
• It should be possible to switch to the "Instance selection" via the account menu.

[Eladnarlea]

@luke- I would suggest to position Switch HumHub Instance either under My Profile OR above Logout

Under My Profile

Above Logout
(Icon would be changed as in the screenshot above)

[luke-]

@Eladnarlea I would prefer above Log Out

[marc-farre]

I share with you how https://www.mightynetworks.com allows switching instances on their mobile app.
They call the button "Switch network" which might be more intuitive to general public than "Switch HumHub instance".
They use a sidebar offcanvas (sort of modabl box on the side, see https://getbootstrap.com/docs/5.3/components/offcanvas/):

[Eladnarlea]

@PrimozRatej I have sent you a pm via Element to discuss possibilities of UI elements to use. After your validation I would post it to this issue.

[Eladnarlea]

Please find the suggested design solution below.

The idea:

1. Show up to three last logins to avoid cluttering the interface
2. when clicking add network you will be guided through the existing flow
3. Need help should still be visible on the first front screen

@PrimozRatej I know that I already asked you if it was possible to display the fav-icon. But do you maybe know whether you can also show the logo of the network in the app preview? I guess so, but please confirm :)

Screen.Recording.2024-08-14.at.9.59.21.AM.mov

[PrimozRatej]

@Eladnarlea, I can access the favicon through https://community.humhub.com/manifest.json. I assume the network's logo is different, so I think we would need to add it to the manifest or make it accessible through some kind of open API.

[PrimozRatej]

@Eladnarlea, there's no need. If there are any changes, we can address them in the second iteration.

[marc-farre]

@PrimozRatej In older versions, once logged in to a HumHub instance, it was possible to display the app homepage form (to enter another HumHub instance) URL, by swiping right from the left edge (or clicking on the Android return button).
On v1.0.110, it displays "Do you want to exit an App?".
So we need to sign out each time we want to switch to another HumHub instance.

[PrimozRatej]

@marc-farre, @luke-

This is the current impl.

https://github.com/user-attachments/assets/af215d4a-0658-43ff-a278-4d40e25931c3
Once the user navigates to a specific instance, there is no way to return to the opener page, where they could then navigate to another instance from their list.

The idea I had here is to implement a JS channel, similar to what we did for isHideOpener. When the user logs out, we navigate them back to the opener page. This works, but it requires the user to log out in order to return.

To allow the user to stay logged in while still switching between instances, we would need a 'Switch Instance' button. I was thinking this could be placed in the menu.

When this is clicked, the JS channel switchInstance will be triggered, and we can redirect the user to the native part of the opener. This button will only be shown for isMobile users.

NOTE: To maintain backward compatibility, we do not want to show this button to users with an older version of the mobile app that does not yet support 'Multiple HumHub Sites.' For this, I can add a custom header isMultiInstanceSupport to ensure the button is only displayed when this is set to true.

[marc-farre]

I think that's perfect.

The isMultiInstanceSupport will be useful for white labelled apps, because for most of them we will set it to false.

@luke- do you approve the idea?
Should I implement this new menu item for 1.17-beta.3?
Name: "Switch network"? Other idea?

Do we keep Last logins: or should we change for My networks:?

[PrimozRatej]

The isMultiInstanceSupport will be useful for white labelled apps, because for most of them we will set it to false.

Ah, I forgot about white-labeled apps. I think we should support a "Switch Instance" button on all instances, including white-labeled ones. This is because in case users use both the opener app and white-labeled app for same instance.

For white-labeled apps, we can add an additional header: isWhiteLabeled.
The logic would then be:

If isWhiteLabeled == true: Do not show the "Switch Instance" button.
If isWhiteLabeled == false and isMultiInstanceSupport == true: Show the "Switch Instance" button.

Do we keep Last logins: or should we change for My networks:?

I think My networks: it's better.

[luke-]

A thought on HideOpener State

Currently, the app has the “hideOpener” state. In this state, when you press “Back” or open a closed app, the opener is no longer displayed.

If we now allow multiple instances, does it really make sense to continue having this state?

"Switch Network" in User Account Menu

If we decide to add this menu item (might also make sense without the “hideOpener” state - see above), I like the idea with the headers to determine when to show this option.

---

@marc-farre I would like to implement the “Switch Network” in the FCM push module first.
For v18, we could extract general mobile app components into a core module mobile-app. What do you think?

[marc-farre]

@luke- Yes, that sounds good.

We had a discussion with @PrimozRatej about the isWhiteLabeled idea and though we don't need it (the isMultiInstanceSupport is enough).

For the hideOpener, I'll leave @PrimozRatej answer.

[luke-]

Ok. By the way, we already have detection for whitelabel apps via https://github.com/humhub/fcm-push/blob/master/helpers/MobileAppHelper.php#L66-L80

[PrimozRatej]

I think we should leave the isHideOpener state as it is. This state determines whether the app should navigate using the WebView or the native opener screen. If we remove it, navigation back to the native opener screen when the user logs out would no longer work. Also, if the user was using a particular instance before closing the app, it should reopen to the last used instance when launched again if we don't track the state we can't do this.

Ok. By the way, we already have detection for whitelabel apps via https://github.com/humhub/fcm-push/blob/master/helpers/MobileAppHelper.php#L66-L80

I completely forgot about this. Maybe we could use the existing isAppWithCustomFcm implementation to display the switch button. Then, we can reuse the hideOpener JS channel to navigate the user back to the opener when switching or loging out.

What do you think @luke- ?

[marc-farre]

I think we should allow White Labelled mobile apps having multiple instances.
Example: we could have an international organization having one HumHub instance per country.
But they might want one mobile app only for the hole organization.
And the users to be able to log in to several of their HumHub instance (e.g., and administrator manages 2 countries).
We could have many other examples of organizations with several HumHub instances.
So I suggest keeping the isMultiInstanceSupport for all mobile apps.

[luke-]

@PrimozRatej

I think we should leave the isHideOpener state as it is. This state determines whether the app should navigate using the WebView or the native opener screen. If we remove it, navigation back to the native opener screen when the user logs out would no longer work. Also, if the user was using a particular instance before closing the app, it should reopen to the last used instance when launched again if we don't track the state we can't do this.

Ok, then let's keep the isHideOpener state.

Ok. By the way, we already have detection for whitelabel apps via https://github.com/humhub/fcm-push/blob/master/helpers/MobileAppHelper.php#L66-L80

I completely forgot about this. Maybe we could use the existing isAppWithCustomFcm implementation to display the switch button. Then, we can reuse the hideOpener JS channel to navigate the user back to the opener when switching or loging out.

What do you think @luke- ?

That's right, actually we could already implement the button using the existing JS channel. As soon we detect the isMultiInstanceSupport flag.

@marc-farre Can you implement this in FCM Push?

[luke-]

@marc-farre

I think we should allow White Labelled mobile apps having multiple instances. Example: we could have an international organization having one HumHub instance per country. But they might want one mobile app only for the hole organization. And the users to be able to log in to several of their HumHub instance (e.g., and administrator manages 2 countries). We could have many other examples of organizations with several HumHub instances. So I suggest keeping the isMultiInstanceSupport for all mobile apps.

Good point. But this is something for the future. So we should not completly remove it.

[marc-farre]

@marc-farre Can you implement this in FCM Push?

Yes.

[marc-farre]

@luke- @PrimozRatej PR humhub/fcm-push#60

I have renamed MobileAppHelper::registerLogoutScript() to registerShowOpenerScript() because this method is not about login out, but about displaying the app Opener

[luke-]

Looks good for me. Probably we'll rename the link in the next time. But for now it's fine.

Let me know when i should merge and release a new verison.

[marc-farre]

@luke- Primoz is currently testing it on an instance of mine. We'll let you know when it's OK to merge.

[marc-farre]

@Eladnarlea Shouldn't we have the same button hight?

[marc-farre]

@luke- PR humhub/fcm-push#60 is now ready and tested.

I had to change quite a few things:

• The Events const are changed and moved to MobileAppHelper
• The Mobile App admin page Action is moved from the MobileAppController to the AdminController
• The MobileAppController is now accessible to everyone and has the action to switch instance
• I added the new MobileAppHelper::openerState() to know if the Opener page is opened or not (and close it if opened)

Can you review this please? humhub/fcm-push#60 (comment)

[luke-]

@marc-farre Thanks. Looks good for me, but I'm not tested it. Just looked over the source.

Btw: I'm also not that happy with my original implementation using the session variables (etc.). But I can't actually think of a better solution here. Maybe we should revise this again at a later date. The code is currently very difficult to debug/understand. (Set session var, new request, check if, ...)

[PrimozRatej]

@marc-farre, @luke-
Test apk: app-release.apk.zip

In this PR, some major changes were introduced regarding the opener page. I am attaching the APK file so that it can be tested internally before we push it to production.

demo_video.mov

[marc-farre]

Just tested it successfully.
2 remarks:

1/ after clicking on the "Switch Network" button, it would be better to display the instance buttons instead of the URL form

2/ after switching second time, the CUZY. APP button disappear

[luke-]

I've only seen the video and haven't tested it myself, but it looks really good! That will be a really great feature!

Should @mbumpalumpa take a look regarding design?

[marc-farre]

Yes, @mbumpalumpa if you can advise if the button heights are fine or if they should be the same on the same row (for the "Add Network" button, and when the button name takes 2 lines)?

[PrimozRatej]

https://github.com/humhub/app/releases/tag/v1.1.0