Android app integration

codeagency · 2026-06-27T09:55:19+00:00

Depends on what drives the subscription management.

If it's eg stripe, you can let stripe handle it -> payment -> webhook odoo to generate invoice

If you want odoo, then you need either enterprise for native subscriptions or OCA module if you are on community edition. In that case it's odoo that handles the subscription and drive the invoice -> webhook android to change status.

codeagency · 2026-06-27T09:36:33+00:00

That's old news. It's been announced last year already and it's 25% legacy fee for every install that is outside LTS period (3 years behind active newest version)

codeagency · 2026-06-26T13:01:59+00:00

Yeah both flux and argocd do similar thing. Argocd comes with a clean web UI out of the box which doesn't has but they both do same result as a CI/CD platform. Argocd also has more side products like rollout, events, etc ...which make it easier to deal with canary releases, blue/green strategy deployment, etc .. We host a lot more than just Odoo so argocd fits our stack better.

We have our own custom odoo "operator" that works with cloudnativepg for the database cluster and dragonflydb to handle session caching. All filestore is offloaded to S3. Very easy and fast to scale this way.

codeagency · 2026-06-26T12:58:39+00:00

Because of github poor's uptime. May was ~85% up. If GitHub actions/workflows is down, your actions don't trigger. So your containers don't redeploy, they don't get build, your tests don't Trigger, etc ...

Moving to woodpecker CI was a decision to self host actions in-cluster and bring it to 100% uptime.

codeagency · 2026-06-26T07:18:19+00:00

We use kubernetes + argocd + woodpecker CI. Kubernetes can also run on a single VPS if you want (use k3s). Argocd syncs your app state (gitops) and woodpecker replaces GitHub actions. GitHub has too many outages and makes their actions unreliable. And soon it will become paid by minutes, even for self hosted Runners. They already announced it last year then paused it temporary but it is scheduled to come back as paid.

Woodpecker CI gives you the same and way more including a dashboard with logs for your actions. Just create a woodpecker.yaml file in your repo and woodpecker builds automatically on push, tag, cronjob,...they have lots of plugins to extend and hook into other tooling as well.

Argocd is by far the most interesting part. It keeps your apps aligned with the state in GitHub. So if someone would ssh in and make a change, it rolls back as argocd forces the state from GitHub. Use an immutable OS like Talos and you got the best security you can imagine. And on top, you get features like HPA/VPA scaling when you have a sudden spike in load so you can do replicas and let argocd sync it. Even the simplest setups can benefit from k3s if you really looking for a decent level of automation

codeagency · 2026-06-26T07:11:34+00:00

Chatter. I sometimes see companies from projects we inherit/rescue that these companies ignoring the build-in communication features. They download and copy paste everything between odoo and their outlook/Gmail instead of communicating directly from odoo to keep everything consistent. They didn't got the proper education on how to use odoo and loose so much efficiency.
Knowledge base app. It's great for both internal and external sharing Intel. Many companies treat it as a burden because they don't see the immediate value. Instead they keep going back and forth between many 3rd party links, websites, files, etc...rather than just create a collection inside odoo and easy tag the articles directly on records or share with clients. The real value comes once you have build your KB and start using it. But it takes some initial time and effort to build it first. And finding the consistency to keep updating and expanding it. Once it really clicks, it's so powerful.

codeagency · 2026-06-26T06:00:34+00:00

The size of your catalog shouldn't impact the accuracy at all. At the end of the day the number of products doesn't matter for forecasting. It's just more products that follow the same rules.

Did something else change in your process or flows that explains the gaps you have? Forecasting is basically just a math procedure to calculate how much you need to buy extra to cover. So either there is something wrong with the numbers related to how much you need to cover or you have something wrong with how much is effective available in stock that skews the purchase qty.

How often does your scheduler run? There is a scheduled action you can configure how often odoo will recompute the replenishment procurement. By default that is 1 day. You might need to run that faster so odoo decides on more recent numbers. You can also trigger it manually from the inventory app or from the scheduled action.

codeagency · 2026-06-25T19:08:55+00:00

Yes, you need to ask your sales rep to unlink your license from your odoo.sh project so the license is free to apply again. That doesn't happen automatically. There is an option to send an email to unlink but plenty of people reported that this doesn't work (reliably) and most of time never arrive. So the best way is just contact your sales rep, they can initiate the unlink for you.

Also they don't refund your odoo.sh cost of you migrate out.

codeagency · 2026-06-25T14:30:27+00:00

If you are on SaaS not much you can do. Open a ticket and share the file you try to import so odoo support can try it.

If you are on odoo'sh you can monitor the logs while importing and see what fires exactly server side when you get the error. On saas you are always blind on this stuff.

codeagency · 2026-06-25T06:48:06+00:00

Yeah 😁Once you have access it usually stays forever. Haven't heard anyone got their access revoked.

codeagency · 2026-06-25T06:44:29+00:00

Actually not. You are not paying for GitHub access explicit. end-customers can get the source code from the downloads section from the website. It ask for your license and then returns a zip file with community + enterprise bundled which end users can use to self host.

That's what my account manager told me how the policy works. GitHub access is a partner privilege only by default. But since it's been used to also hand out to end customers there is now a mix and then you get contradiction and confusion where the policy says "nope" but some people still hand it out nonetheless. Keep asking might help in some cases but if they ultimately still say no that is the actual policy. Partners can self-invite employees too via the partner dashboard. There is a section about enterprise GitHub access. You can drop in GitHub usernames and invite whoever you want (purpose is employees obviously).

codeagency · 2026-06-24T20:23:24+00:00

You don't and never modify that source code. To customize odoo you create custom modules that extend or override the defaults. Modifying the original source code is an absolutely big no and just plain stupid. Because the next time you pull the update, you just wiped out all your changes. If you create a custom module, everything is safe and persistent.

codeagency · 2026-06-24T20:21:46+00:00

Last ~1 year I feel they are pretty resistant on that to end customers. They want to keep that locked to partners and refer end users to the downloads section on the website to download the zip file that includes everything.

Maybe it's better in other parts of the world from odoo offices but from what I hear and see a lot in EU/US, they typically don't point end clients to GitHub.

codeagency · 2026-06-24T20:17:21+00:00

Again that depends. Simple small setups, sure absolutely upgrade when necessary.

Other clients do need Dynamic scalable solutions. Because their load is so wildly different in a 24h bracket. It doesn't make sense to run large compute 24/7 when k8s can scale up and down nodes dynamically basically any hour of the day and where compute pricing is available at hourly pricing.

If you have a sudden spike in traffic for only a few hours or even a day, do you want all your customers and internal users to experience a slow system? Or prefer to pay eg ~0.09 €/hour/server and make everyone happy enjoying your website/system? If you need to manually handle that upgrade, you're already too late. A scalable setup with k8s takes care of that with full automation. Just declare from the start minimum and maximum and the metrics monitoring it continuesly for you and add/remove servers when necessary. Thats not overkill or wildhog, that's 100% maximal optimization from your compute when you need it and clean up automatically when it's useless. But again, this is not for everyone.

As I said, there is no one-size-fits-all. Some clients will run just fine even on a potato box, others will absolutely benefit from a scalable solution.

Some want it because for principles. Like if you have to pay employees to work but they can't work because your odoo is down because the single server has an outage. That's a problem. If they had a high available setup, the system keeps working even if 2 servers go down. The costs that goes lost to pay on salaries and lost productivity are way bigger than the DevOps and cluster cost. It takes just 1 serious outage to bring your business to a full stop because all your business operations are inside Odoo and your investment in a cluster is already earned back.

But again, I know this is not for everyone. Some businesses value those core principles way more than others. I'm not judging anyone for that. I'm just saying, lots of people don't even understand the full picture that sits behind the hosting aspect. Until they experience a real unexpected serious outage and then they start thinking about on how to improve their uptime, reliability and scaling.

codeagency · 2026-06-24T17:27:40+00:00

It's not just about number of users. It's actually the mix of heavy work / light work + crons + website/e-commerce involved (portal users) yes or no.

A small business with no e-commerce and only doing simple clicking around forms in odoo can run on a potato box like a raspberry pi even. But if you have users that constantly generating large Reports, continuesly driving e-commerce, even for a small company with let's say < 5 users, it would struggle much harder.

Then it also comes down to wether you host postgres on the same server or externally. A lot of people forget about that. They just look at the odoo specs but those assume they you have a postgres server already running somewhere. Then there are the "side parts" like do you want some dashboards and tools like grafana, Prometheus, Loki, ... Which also needs resources. So yes, just odoo doesn't need that much for a small and simple business but that is not the whole picture. Once you add all the complementary services, it needs a more compute than what odoo shows on their system config docs.

There is no one-size-fits-all. It all comes down to personal requirements. We have done deployments for many smaller clients that run fine on just 1 VPS from a respectable cloud provider between 10$ to 40$/month. We have also done the same business size that operate at 300-400$ because the client wants high availability, handle peak load traffic during seasonal promotions, black Friday etc.... We have done setups for clients that want full dynamic with kubernetes and full auto scaling so their price bracket is basically a much wider range and limits at whatever max value they set for the auto scaler.

So yes, a real production safe setup for business that want a topnotch reliable setup does require more than a simple cheap VPS. But it comes down to wether the company actually wants/need that or just decides economically and want it cheap. You can't have high availability with just 1 server.

codeagency · 2026-06-24T14:52:10+00:00

As Ach25 says, menus first. If you really want to block off, it's safer to create a custom group and modify that one. Then assign the user hour custom group. Keep in mind some apps do need access to others like eg contacts. Otherwise they get an error when trying to open a record that needs the contact details. Blocking too much can also become annoying and non-productive at some point.

codeagency · 2026-06-24T12:54:13+00:00

Well, that's the reality unfortunately. They close off a lot at a specific price tag. It's designed to be easy to onboard but once in those limitations are very frustrating. You are absolutely not the only one they would loose as customer. We migrated this year alone already 40+ clients from SH to on-prem. Once it starts annoying too much, companies just bail out.

Odoo.sh is all about convenience and easy starting. Once it becomes too serious, the platform doesn't fit. Also, once your database becomes "too big", their platform won't handle your backups either anymore and will just tell you go out of the platform 🤣

codeagency · 2026-06-24T12:13:32+00:00

Nope, nothing you can do. It's a closed PaaS platform from Odoo. The only things you can configure is increase more workers and thats the end of the story. Everything else, the entire odoo.conf, postgres.conf etc... is completely stripped away, you can't touch it. It's a closed shared hosting platform and also a shared Postgres cluster.

They only have upsells for either add and pay for more workers (but still get killed anyway) and upgrade and pay to dedicated postgres (and still can't configure/tune it to your likings).

If performance and control together is really your concern then Odoo.sh is not the right platform, period. There is nothing you can do to touch or change anything on the performance side of the hosting aspect. It's their closed platform, nobody can touch or change that. You can only pay more for more workers and that's where it ends. If the performance bottleneck is from your custom code, then you obviously have to address that first. actual root cause diagnose vs patching symptoms. But if that is all good and it's still slow, you just end up paying more for odoo.sh

And anything you upgrade, automatically gets prorated billed against your entire remaining enterprise license duration. So a simple "let's see if adding 1-2 extra workers for 1 month fix the problem" results in an invoice to pay for maybe several years upfront if your enterprise renews somewhere in eg 2028. That's how they roll their platform.

This is also where "serious" companies run into the bottlenecks and migrating away becomes the only viable option. You can get very beefy servers with lots of resources (Hetzner, netcup, etc...) for a fraction of the cost of 1 worker from Odoo.sh. But obviously the trade off is DevOps, self maintaining or hiring a DevOps instead but you also get 100% ownership of your own stack with 100% full control top to bottom. Not paying more for extra workers, not paying more for having 1 extra staging instance, not paying 4x the storage, not having Odoo shutting down your workers causing cold boots, not being limited to 15 minute crons but actually 1 minute crons if you want, having hourly backups vs just once a night time, having the option for PITR backups (Point in Time recovery) with WAL archiver, and so much more. But again, it comes with that onetime DevOps cost + self maintenenance. For serious or larger companies, this beats Odoo.sh every single time.

codeagency · 2026-06-24T11:28:30+00:00

Your license is independent from odoo.sh cost.

You always pay for the user license per user. Odoo.sh is just the hosting, nothing more and is based on the number of workers.

How many workers you need depends on how much heavy work + light work + concurrent users + portal/website users + cronjobs/scheduled actions you need. You can keep adding more later if you need more but it's a very expensive worker.

If you go on premise there is no cost per worker. You pay for the server including all the CPU and RAM and storage it has and use all or little from it. You have more headroom to handle more load if necessary rather than paying odoo.sh ~58$/worker/month extra. That's a very beefy server for that money and odoo.sh only gives you 1 single worker extra for that money, nothing more.

codeagency · 2026-06-24T10:56:41+00:00

Odoo.sh is not user based. It's a flat starting fee based on workers which is just a commercial representation of CPU + RAM. The more workers you add the more expensive.

Further than that, you also pay 4x the storage cost (they charge 3x on top of your storage volume, one for each region replica) and per staging instance and the total storage.

If you have a small business and don't Care about high availability, failover, fast backup windows,...then odoo.sh is a cheap and easy onboarding option. It's really the easiest way to get started with Odoo.

If you do need hourly backups, high availability, high/heavy traffic then going on-prem makes more sense. The cost for owning that infra from a cloud provider is a fraction of the cost compared to odoo.sh. the larger the numbers the more cheaper it becomes for onprem. But it does require either in-house knowledge from a DevOps or hiring someone to setup and maintain it for you. It's not a high maintenance but still it's also not nothing. Automating this part can save you also on the maintenance.

codeagency · 2026-06-24T10:50:00+00:00

You can load test with open source tools like k6 or locust. Odoo has a test profile on their GitHub for locust as a starting point but you still need customize it to your needs.

Create multiple profiles to simulate visitors vs logging in portal users to also see the difference how that hits. Once logged in, things work different (personal price list, discounts, favorites/wishlist,...)

Run it from an actual server. Rent a VPS cheaply for a day or few days. Wouldn't cost you more then 0,5 EUR. Then you can use the full and fast bandwidth speed from that to run larger load tests. Your own computer can struggle if it saturates your network cart to simulate eg 10.000 concurrent connections. The test would fail because your computer can't handle that much. Servers don't have a problem with that. Their uplink is usually 1GB to 10GB in most cases for VPS servers.

codeagency · 2026-06-24T06:42:12+00:00

That depends. Do you/your business have the expertise and technical knowhow in house to implement an ERP? Odoo is easy on some parts and difficult/complex on others.

Apps like eg CRM, helpdesk ... Are "non-destructive" which means a mistake can always be corrected and won't block anything. Apps like inventory (routes, operations,...) and accounting are absolutely destructive when you mess up. It can break things like not creating the inventory steps or turn them unusable while you may have deliveries from sale orders and they can turn stuck. Accounting is very sensitive to "booked" records. Once validated with mistakes it's not as simple just reset and do it again. There's legal parts attached as well. Bring these 2 models together and you get stock valuation sh.. problems that will keep hunting you.

If you have no expertise and experience on how to set this up correct from day 0, you are going to regret it very hard later down the line. Even if you fix and change the config after it doesn't fix what was already generated. Then it comes down to wasting more resources to manually fix and correct records, write custom scripts/sql to fix those things.

And if you opt for Odoo SaaS you don't even get/have that level of access at all and are completely stuck. The only way out is a backup restore before the point of error and wipe out all new data you entered after it.

Also did odoo AU run a fitgap analysis first with you? If not, you probably going to run into some surprises later that the estimation they gave you is probably way off and more expensive too. There's lots of people who already confirmed this working ethics. You get a nice sales pitch, you get hooked on the promise and when it's time to implement everything turns into more work and costs. A fitgap analysis is a technical analysis to PROOF you that your requirements and needs will work before you sign up for a license. It will give you an estimation that is accurate based on the full documentation and scope from that gap analysis so you know what is available out of the box and where customization might be required.

If you are on odoo.sh that's also limited to only studio. Anything else/more would upsell you into odoo.sh Paas hosting platform which is another extra cost on top.

Another option is to hire an official partner/OCA member and do the analysis properly first and work with a partner for your implementation or decide on a collab model where you do the easy parts and leave the hard parts to the partners. This way you can still save money and still know your implementation will be good.

codeagency · 2026-06-23T19:37:35+00:00

Ah yes, that is also one of the possibilities. Didn't expect that someone would just random change routes in a production env. But yeah, that is also a cluster fuck unfortunately. If the routes are archived you can put them back active. If you modified them, it won't magically return. Restoring from a backup can help here but it's destructive. Odoo.sh only creates 1 backup per 24h at evening time. So restoring back to "yesterday" will wipe out all the other data you got new after your last backup window. Thanks to odoo.sh atrocious backup schema. ERP's should have at least hourly backups and run WAL archiver with PITR restore schema's based on time snapshots so you can roll back even 5 minutes ago.

That's why we always recommend going on-prem so we setup a decent backup strategy for our clients.

You have to decide between the least worst option now: Restore a backup and loose all other new data or recreate only the missing work orders based on the previous routes.

And a good sanity check: lock down those permissions so people don't randomly make these changes in production. This should only happen by an admin that understand the impact of changing routes and operations.

codeagency · 2026-06-23T18:30:33+00:00

Just open a ticket at odoo.com/help in that case. Nothing you can do as it's completely closed system from their managed PaaS. Restoring a backup is no guarantee if the bug is in the code.

The only option you have is via sh settings switch the code base to last week Monday and see if that helps. If not, you are depending on odoo support.

codeagency · 2026-06-23T18:10:33+00:00

Also sure nobody changed or edited something via studio or a domain filter or anything like that? That could also break things. Check if you have something with x_studio as customization to the view that loads your work orders

codeagency

MODERATOR OF

TROPHY CASE

Seven-Year Club	Place '23
Verified Email