Cannot activate Enterprise license
-
Hi there,
I'm trying to import/activate an enterprise license for Docmost and upon saving, I am getting the following error:Cannot POST /api/license/activate

Looking up trying to find if this was an upstream issue, I found this:
https://github.com/docmost/docmost/issues/1856Could this have to do with Cloudron's way of building the app package?
If so, how to we get around this?Many thanks,
-
Hi @james
Thanks for the quick reply.I do see error in the inspector - namely this one:
/api/license/activate:1 Failed to load resource: the server responded with a status of 404 ()attempting to browse https://mydocmostaddress.mycloudron.io/api/license/activate also resolve in 404

This is the same behavior across 3 different browsers and devices.
-
Just a quick complement if this helps: One can get a 60 days Docmost Entreprise Trial license by registering on https://customers.docmost.com/register
-
Hello @teiluj
We build Docmost from the GitHub source tarball, but the EE features (including
/api/license/activate) live in a private git submodule (docmost/ee) that isn't in the tarball. The officialdocmost/docmostDocker image contains the pre-compiled EE code (verified:/app/apps/server/dist/ee/licence/license.controller.jsexists there). Fix would be to repackage the official image on top ofcloudron/baseinstead of building from source.We had various cases where other apps shut down the paid version access without notice, leaving us with no way to push updates.
One example would be the recent change to @cal.com https://forum.cloudron.io/topic/15399/cal.com-closing-source
If they don't release the enterprise part for us to build a package from and dealing with those docker images has often led to more problems, see https://forum.cloudron.io/post/123514So we got very hesitant to switch Cloudron apps like that.
Just for us to know, do you just want to try the enterprise version or do you plan to fully use it? -
Hello @teiluj
We build Docmost from the GitHub source tarball, but the EE features (including
/api/license/activate) live in a private git submodule (docmost/ee) that isn't in the tarball. The officialdocmost/docmostDocker image contains the pre-compiled EE code (verified:/app/apps/server/dist/ee/licence/license.controller.jsexists there). Fix would be to repackage the official image on top ofcloudron/baseinstead of building from source.We had various cases where other apps shut down the paid version access without notice, leaving us with no way to push updates.
One example would be the recent change to @cal.com https://forum.cloudron.io/topic/15399/cal.com-closing-source
If they don't release the enterprise part for us to build a package from and dealing with those docker images has often led to more problems, see https://forum.cloudron.io/post/123514So we got very hesitant to switch Cloudron apps like that.
Just for us to know, do you just want to try the enterprise version or do you plan to fully use it?@james Thanks for looking into this - this is what I feared.
As far as I can tell, Docmost has not changed its licensing model in a recent past or at least not since becoming an app available on Cloudron.
Additionally, I have some vague recollection of similar situations with other apps on Cloudron (a quick search reveals apps like Baserow and Mattermost)
For now we are looking at trialing Docmost enterprise with the ultimate view to possibly adopt it for all the benefit and additional features it provides.
For example, things like OIDC is locked behind the (trial) license and it is not quite clear if/how we would connect it with Cloudron as an OIDC provider for now.How has Cloudron approached situation such as this one (if any)? was it through direct contact with the dev-team? If so, would it help if I attempt to put you in relation with a relevant contact? would the best way be for the docmost dev(s) to contact support@cloudron.io directly?
I suspect that building the Enterprise version of Docmost would not get away from needing a valid license.
Also, I do not think that pulling a partly private app image conflicts with having an open source cloudron app package residing on cloudron gitlab does it?
Possibly it just requires an agreement and permissions between Cloudron and Docmost. -
Hello @teiluj
We build Docmost from the GitHub source tarball, but the EE features (including
/api/license/activate) live in a private git submodule (docmost/ee) that isn't in the tarball. The officialdocmost/docmostDocker image contains the pre-compiled EE code (verified:/app/apps/server/dist/ee/licence/license.controller.jsexists there). Fix would be to repackage the official image on top ofcloudron/baseinstead of building from source.We had various cases where other apps shut down the paid version access without notice, leaving us with no way to push updates.
One example would be the recent change to @cal.com https://forum.cloudron.io/topic/15399/cal.com-closing-source
If they don't release the enterprise part for us to build a package from and dealing with those docker images has often led to more problems, see https://forum.cloudron.io/post/123514So we got very hesitant to switch Cloudron apps like that.
Just for us to know, do you just want to try the enterprise version or do you plan to fully use it?Hi @james, founder of Docmost here.
It would be awesome if you consider basing your build on the official Docmost image.
Since Docmost is self-hosted, we don't restrict where users can run the software.
We made the enterprise module separation of concern as clean as possible. It is bundled in our official build process and only gets called when an enterprise license is activated. It don't interfere with the core app.Having this supported would make life easier for users who wish to use Cloudron and also benefit from our enterprise features such as SSO, AI, page verification workflows and more.
Please let me know if there is anything I can do on my end to facilitate. Happy to reach out any other ways you suggest.
Thank you. -
Hello @philip and welcome to the Cloudron forum
It is great to have you here.
I have validated the mail address you used in our forum against your GitHub profile and thus added you to the App Maintainer group to signal to users that you are indeed who you are.Changing the build from source to copy from the source image is a simple change which we could make.
The question we have is, why is it not part of the normal build from source, but in a private git submodule?
Like I wrote above, we had multiple bad experiences with for example @grist and @cal.com who suddenly decided to remove public access to enterprise features, even for paying users who self-host.
Since people rely on software and updates and are paying for them, these decisions are detrimental.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login
)