How to deal with /app/data/ which is also part of an update

[BrutalBirdie]

Hello fellow @appdev 's

I am coming to you with a question and a wish for recommendations.

The app I am referring to as an example is Greenlight.

There are parts of the app, like /app/data/locales and /app/data/views which are needed in /app/data for user customization.
Ref Doc: https://docs.bigbluebutton.org/greenlight/gl-customize.html#customizing-the-landing-page

But here comes the problem. These files/folders are part of the app and need to get updated, but also are not supposed to get overwritten by an update.

So what to do? - I have initial thoughts for the update process.

Compare (git diff style or md5 hash) /app/data with /app/code and if the diff/hash is equal then just override with the newer files.
But when the diff/hash has changed then leave it as if.

When using diff style comparison I could store the diff from /app/data somewhere, do the update and then apply that diff.
But I can already smell this failing in the long run.

So what to do, notify the user with every update:

"Hey if you made changes to your /app/data XY file you need to merge them manually".

This is not what Cloudron users expect from apps. I (the user) want an app which I can use and don't need to do manual updates.
That's why I have chosen Cloudron in the first place.

Looking forward to read your responses.

Cheers,
BrutalBirdie

[mehdi]

@BrutalBirdie I don't understand how it's supposed to work on a normal file-system.

You say that these folders "need to get updated", but also "are not supposed to get overwritten by an update". These 2 sentences seem contradictory to me.

[atridad]

@mehdi I imagine its a typo.

[Lonkle]

Yeah, that kinda through me as well. Even if it is a typo, I still don't know what he means by it.

[girish]

@BrutalBirdie said in How to deal with /app/data/ which is also part of an update:

But here comes the problem. These files/folders are part of the app and need to get updated, but also are not supposed to get overwritten by an update.

I think the matrix app also had some email templates like this one. For matrix, atleast, I decided not to make those customizable because editing them is going to make it "unmaintainable". IIRC, the templates also threw some exception if some fields are missing. So, just make a judgement call based on how common it is to edit those things.

If it's common, usually the Cloudron approach is to leave them alone after update. (not diff'ing/merging etc). In cases, where things are "mergeable", we merge settings from the upstream and the user config (for example, ini files, xml, json can be merged).

[BrutalBirdie]

@mehdi said in How to deal with /app/data/ which is also part of an update:

@BrutalBirdie I don't understand how it's supposed to work on a normal file-system.

You say that these folders "need to get updated", but also "are not supposed to get overwritten by an update". These 2 sentences seem contradictory to me.

Yes that IS the problem.
I did not write this sentence with the intend of, I want it to work this way, no I wrote it more like this is the dilemma / Paradoxon.

Greenlight can only be customized by files which are part of the application which want updates but users don't want to override since the made custom changes.

The normal workflow for Greenlight would be to fork the project and maintain your own fork.

[nebulon]

I guess for our greenlight app, this can only mean for now to simply not make it customizable in that way. Forking makes no sense for general purpose usage, but is of course always possible in edge-cases by building your own Cloudron app package. So unless the app does not work without customization (which from my experience using it is not the case) then just leave them in read-only directories.

[BrutalBirdie]

Tagging @luckow since he has customer experience with Greenlight and could tell us how often a customer wants/uses to use this feature.