SOGo and WebTop

Hello,

Is it safe to install webtop and SOGo at the same time and run them next to each other for testing?

What is to be considered?

For me is currently SOGo the standard platform and with CalDav are the smartphone and tablet connected, that should remain so first.
The first test did not work 7 months ago.

Grettings,
Gerald

Only one software can run activesync, sogo takes over webtop, but you can deactivate activesync on sogo and uses it with webtop

Apart from this, I do not know any other issue

1 Like

AFIAK the card-, cal-dav conflict is not addressed jet.

And with the latest Nexcloud there is a 3rd application who would like to have /.well-known/carddav and /.well-known/caldav redirected to it. The latter is not implemented jet, so no worries here. But it does not make it easier find a solution. :thinking:

Sounds like something that needs to be addressed. Perhaps a configuration property (config set dav configuration caldav {nextcloud|sogo|webtop} carddav {nextcloud|sogo|webtop}) . That allows for the possibility of adding other apps in the future. It also makes it a system-level configuration, rather than app-level, avoiding the possibility of conflicts (as currently exist with activesync).

2 Likes

Though of this too, but failed to get the logic in my head how to act on installation and removal of a module. :disappointed_relieved:
Assume you install webtop first, clearly “webtop” is allowed to set it to itself. Then you install nexcloud, IMO the setting should not be touched by nextcloud. So far so good…, now remove webtop… and to elaborate on this: what if you installed a 3dr package and remove the first one…
How can we end up with sane settings? :thinking:

What about this possibility:

  • We expose the setting in the server manager somewhere (as a drop-down, I’d think), including “none” as an option
  • This means the server manager needs to know what handlers are installed. A “brute force” way to achieve this would be to just check whether nethserver-{nextcloud|sogo|webtop5} are installed; a more elegant way would be to implement some sort of registry of handlers. Or just require the system admin to know what’s installed on his system, and expect he won’t choose poorly–though I’m not a fan of that plan.
  • No app sets itself as the handler for cal/carddav
  • Therefore, the user explicitly chooses among the available apps
  • When nethserver-blah is removed, it queries the dav property to see if it’s set as the cal/carddav handler. If so, it sets that handler to “none”.

Seems like this should cover the possibilities. Thoughts?

1 Like