Server-tools: [RFC] module_auto_update: Community Module Updater

@lasley and anautomatic git fetch and git reset? I'd love that.

Not everyone uses Git, so this is not possible.

:+1: for the community update feature.

A few of our instances still aren't Dockerized, so I might actually be ok with adding git handling as an option in order to make legacy a bit easier to work with and push back upgrades a bit.

The one issue we'll run into, at least in my deploys, is that the Odoo user does not have write access to the module directories except in some rare instances (and even then, only their ./static dir). Is this not the case for you @Yenthe666?

Hi @lasley,

Nope, we don't have that problem. Our Odoo user has access inside the /odoo folders exactly for this.

Regards,
Yenthe

Also @pedrobaeza this could be easily configurable as a setting to allow it for those who want it or use git.

OK then

@Yenthe666 - It's easy enough to add the feature, so we'll go ahead and implement this. It'll help out in our dev environments too, which don't have the security that our prods do.

As a note, I don't recommend the configuration to allow the Odoo user write access to files it doesn't explicitly need to write. This is a common attack vector for other CMS like Wordpress and Magento - so I feel like it would be the same here. Basically if an attacker gains control over Odoo, they can plant malicious code in places where you would never look.

One solution is to forget about git and versions, and use SHA checksums instead. The ir.cron job would:

1. Generate a checksum for the whole addon folder.
2. Check it against the last checksum it had stored.
3. If it has changed, set the addon to update and store the new checksum.
4. When finished doing this with all addons, trigger the update system.

@lasley We have this module that partially covers what you suggest and also the autobackup https://github.com/ingadhoc/odoo-support/tree/9.0/database_tools.
We have already presented on odoo days and oca sprint days but it didn't catch attention
You can check the presentation available on the readme. We have add a "cli" so you can fix database from command line with something like "odoo.py fixdb". While fixing db it starts a webclient on same xmlrpc with a static page telling that you are under an upgrade.
There are lot of ugly things in the module but we are using it on production fore moreless 3 years

@Yajo - Oh snap good idea. RFC updated. Does it make sense to just generate the directory checksums on Odoo boot, or maybe we need a button?

@jjscarafia - Sweet thanks for dropping a line! Looks like this module duplicates a lot that we already have in OCA, but I see some totally useful stuff here too. Unfortunately though, I will be integrating this into my SaaS & thus require an LGPL licensing instead of AGPL. I would love to be able to use some of this code and give you co-authorship, but I would need to be able to release the version here under LGPL.

I guess the default "Run cron now" button would do the trick. It would be needed indeed IMHO, but you have it there already.

I'd also be as less smart as possible and let checksum_installed empty by default. Next cron iteration would consider it a mismatch and update everything. And from that point, all would be good. Cron should be preconfigured to run at 3AM or so.

@lasley Yes, its duplicate a lot, but this one was before oca one exists. I've a pending task to check oca ones a deprecate that functionality when migrating to odoo 10, so aligned with that, to have the update modules functionality in another module would be great. Still not very familiar with the implications of changing to LGPL, but no problem for me. What should I do to allow the use of the code and change of license?

@jjscarafia - The main implication for LGPL is that it is possible for someone to make a closed source derivative of your app, so they are definitely pretty heavy. Take a look at this breakdown which is overly simplistic but I think gets the point across.

You'll see that the "Same License" only applies when the derivative is not using your software as a library. In layman's terms this means that GPL and AGPL license will bleed into anything that depends on your module in the manifest. LGPL will only bleed into code that makes modifications to the actual code of your module, so simply depending on it in the manifest will allow you to choose any license (possibly proprietary).

All we need is your go-ahead for the permission & license change. My team will migrate the stuff we need, then tag you in the PR and get your approval there. We then have ourselves a record of you agreeing to the change, and we're good to go.

I haven't gone too deep in your module, but I was kind of curious what the fix_db part does? Does that just run an update on everything?

@lasley thanks for the link and the explanation, much clear now. Ok, for me, I wait for the ping on the PR.
This method is callable from database interface and runs an update on every module that requires the update (regarding changes in latest and installed version)

The cli "fixdb" call that method for every database (if you dont specify any) or for the -d database.
We use that on the entrypoint of hour docker image so when running container we always update modules if needed

Closing to track in #882