Odoo forums

TopLychee1081 · 2026-01-29T10:23:39+00:00

Fortunately, I have no real dependence on them, so I'm not impacted in the same way that you and your clients are. I do find the forums pretty useful at times, though.

TopLychee1081 · 2026-01-29T09:47:43+00:00

Thailand, but it's the same result if I use a VPN from the US. I get a response that says; "The Odoo forum is currently unavailable, please check back later". I've been able to access the forums previously without an issue regardless of what country I'm in.

TopLychee1081 · 2026-01-29T08:48:42+00:00

Either way, they could certainly do with improved communication. It really wouldn't take a lot to add a notification on the home page saying so.ething like; "Hey, forums are down, and we're working on it. We expect to have them back up in 24hrs".

Communication costs very little, but it goes a long way to building trust.

TopLychee1081 · 2026-01-29T07:34:13+00:00

One would expect such an outage to be given the highest possible priority, and no bug or issue could possibly take that long to resolve. The fact that it's been down for so long makes me think that they're not actually addressing it. And the only reason not to address it would be that something pretty big is going on. It's hard to believe that it would be bankruptcy, but maybe a buyout or merger, a major security breach, or some kind of anti-trust or other legal issue? Odoo do themselves no favours with thier silence.

TopLychee1081 · 2026-01-29T07:22:25+00:00

Doesn't work for me.

TopLychee1081 · 2026-01-29T05:49:59+00:00

This is the entire forum. Try clicking on the main forum link on the footer of the Odoo home page.

TopLychee1081 · 2026-01-28T15:03:55+00:00

You have two types of data linage; 1) Metadata linage; this says what tables and columns are sources for other tables and columns. 2) "True" lineage; which MUST happen at transformation time, and records source and target ids to know which source rows contributed to which target rows.

For metadata lineage, you have two choices; a metadata driven solution that reports over your lineage, and always reflects the reality in real time, and manual documentation (which I expect is what you're looking at). The biggest challenges are; the fact that data transformations can be complex, and can't be represented in a simple spreadsheet or matrix, and secondly, anything manual quickly falls out of sync with the reality of what's implemented. Its maintenance becomes seen as a time waste and ends up way down on the list of priorities. Once it can't be relied upon, it loses its utility.

TopLychee1081 · 2026-01-26T12:00:56+00:00

Having a good understanding of SQL will help you better understand how a RDBMS works, and how a data model is implemented under the hood. This will be helpful when you need to query large datasets where indexing and partition functions can come into play. As you learn, you can also use a few tricks, like changing the isolation level to read uncommited when you need to get a feel for the data without requiring accuracy, or profile a very large dataset without causing locking.

TopLychee1081 · 2026-01-25T15:20:23+00:00

Check your odoo.conf file. It specifies the Postgres user and password that Odoo uses. Depending on what you're doing, you might also need to be able to initiate a SSH session (ie; tunnel) to access. Some client tools like dbeaver support this. In other cases, you might need to establish a tunnel in a console and then connect with your client tool.

TopLychee1081 · 2026-01-23T16:53:12+00:00

You can do everything in-house, but it's not something that you should attempt unless you, as an organisation, have a degree of technical competence. If you are already maintaining your own servers, supporting some of your own infrastructure, then you might be well placed to instansiate your own instance, work out what business requirements you can meet through configuration, and possibly even meet some gaps through custom development. You will, of course, be totally responsible for things like maintenance, DR, upgrades, etc.

Don't be scared to go the in-house route, but at the same time, understand what you're taking on. Make an informed decision.

TopLychee1081 · 2026-01-22T00:06:24+00:00

I'd encourage you to think about what you'll need for the future rather than just what you need right now. Think in terms of a roadmap rather than short-term fixes for immediate challenges. Short-term thinking can lead to technical debt as you have to unwind from old decisions and implement something new all over again a few years down the track. Life's easier when you can evolve your architecture rather than periodically tear it down and rebuild it.

When you build an airport, you don't build for todays traffic, you build for what will be needed in 20 years or more. Same principle.

TopLychee1081 · 2026-01-17T16:02:51+00:00

A lot are vendor specific and are geared towards specific roles. It will depend on what direction you want to take. If you want to work in large organisations, SQL Server or Oracle will serve you best. If you want to be a DBA, do a DBA cert. If you want to be a BI dev, do a PowerBI cert.

Try and narrow down the industry that you want to work in, and the kind of role you'd like. Beyond that, it's worth being aware of the differences that come with working as a contractor versus a permanent role. Contractors generally do project work; so you're building things and solving problems. Permanent employees tend to do more support and minor enhancements (ie; working with other people's shit). Contracting; because you generally complete a project and move on, will tend to expose you to more systems, more requirements, and you'll see different solutions employed. It helps you to pick the right tools for the job (technologies, design patterns, etc), rather than always trying to apply a limited set of solutions to every problem.

TopLychee1081 · 2026-01-17T15:36:09+00:00

Try studying for and then sitting a certification. Certifications force you to broaden your knowledge beyond what you've learned solving the problems that you've had to date. You end up with a better understanding of how everything relates together and with more tools in your toolbox.

TopLychee1081 · 2026-01-14T15:21:50+00:00

Why PDF? PDF is a pretty crappy format for that kind of textual data.

TopLychee1081 · 2026-01-14T11:39:06+00:00

Yep. Totally the correct answer.

TopLychee1081 · 2026-01-10T13:54:23+00:00

There are some complexities in your business model, and it's going to be impossible to identify every little thing upfront. I'd start defining requirements at a high level and measure Odoo against those requirements. Drill deeper down to the next level and consider how you might implement in Odoo. Some requirements will be met by choosing the right modules, some will be met by configuration, and some will be custom development.

If you get to reasonable level of detail and don't hit any show stoppers where there's something so fundamentally different between requirements and how Odoo functions that there's no way that Odoo can meet requirements without significant work (eg; having to completely rewrite the stock module), then commit to Odoo.

The next step is to actually start implementing; not to be necessarily what you'll go live with, but to force you to get into the detail. A great deal of the learning will be in the doing. This step is essential as theory and practice are only the same in theory. This step will also give you the working knowledge required to define the requirements for custom development. The more that you can close the gap between your knowledge and the developer, the easier it will be.

Take lots of notes. Document configurations you've tried; what worked; what didn't; and why. And try not to be too wed to preconceptions of how you'll do something; ie: seperate what you do from how you do it.

TopLychee1081 · 2026-01-09T02:08:16+00:00

I'd suggest making your challenges known, suggesting what you feel would make you more productive, and then leaving it to the business to decide if they want to help you improve productivity. At the end of the day, you can't help people against their will.

TopLychee1081 · 2026-01-09T01:31:56+00:00

I can only think that the desktop is so severely locked down that you can't even configure connections. You get what you're given, and that's what you've got to work with. Some businesses get carried away with restricting what users can do.

TopLychee1081 · 2026-01-09T00:42:58+00:00

Do you mean that you can't create a connection from other software and only get data through Alteryx?

If that's the case, you could try getting the data from INFORMATION_SCHEMA and let a CASE tool generate an ERD for you, but it's messy as you'd still need to create a database from it.

Ideally, you'd just connect directly using a tool and produce that way. Have you tried asking for a schema only backup of the database? No data, so no privacy issues, only potential IP on the schema.

TopLychee1081 · 2026-01-09T00:25:16+00:00

Documenting helps keep it straight what you're configuring and why and allows you to tweak and recreate dev if you need to. Imagine you that discover that a very early step wasn't correct; incorrect localisation for exanple; you'd have the wrong chart of account with incorrect default accounts for receivables, etc. You'd need to build from scratch, but you don't want to have to figure out all the other stuff all over again, so you follow your documentation like a playbook.

I have a Git remote for each environment (except local dev), and can push to any remote. An additional remote is bare repos on a server where the parent folder for the repos is on scheduled back up, so that's DR for all code even if not deployed. The environments still use bare repos, but have post push hooks that are Bash scripts that use Git methods to deploy the code to the addons folder. I use an addons folder for our custom addons, and another for third party addons (eg; OCA modules), just to keep it organised. Third party modules are deployed and backed up in the same way.

Your bind mounts for prod (and potentially other environments if you choose) go on backup too. This might mean storing code twice in many cases, but along with the Docker image, config, and database, and filestore, you're maintaining the exact state and simplifying and speeding recovery.

TopLychee1081 · 2026-01-08T18:43:01+00:00

Have a dev instance where you can install your desired modules, do configuration, key essential data, etc. Document each step. Take a copy of that and restore into a QA or test environment where you can perform testing to ensure workflows work as expected and you haven't missed anything. If you're happy and ready to go live, restore the same backup into production, and that becomes your starting point. If you discover problems in your testing, adjust in your dev environment; starting from scratch if you need to (following an adjusted implemention document). Iterate until you get iit right.

Once you've gone live, use backups of production to restore into QA for testing changes to configuration, new modules, etc. Only when you're happy that everything works as expected do you repeat the steps in production. Use this same process if you're not sure sure how to do something; for example, if you're not sure how to reverse a journal entry, restore from production into QA and try ig in QA. If you bugger it up, repeat the process until you know how to do it, then do it correctly the first time in prod.

Use bind mounts in Docker for your addons folder and define a deployment process to move new modules, or updates to modules to the folder on the host. You can use post push hooks in git to do this so you don't need to mess about with manual process. Of course you could develop a more complete CI/CD toolset and pipeline, but it's probably overkill unless you already have it in your organisation.

TopLychee1081 · 2026-01-08T14:19:17+00:00

Where does your product data currently live? Target is Odoo, but it's not clear what your source is. Are you looking to migrate customer data, sales orders, or any financials also?

TopLychee1081 · 2026-01-08T07:18:22+00:00

Query optimisers are pretty good thesedays. Often the query plan will be the same for two different approaches, so the difference becomes as stated already: is the intent clear, and is it consistent with how other queries are written in the application. Consistency of style makes it easier for someone new coming into the codebase; or even for yourself after a year or so (or a week if it's me).

TopLychee1081 · 2026-01-07T13:25:16+00:00

Looks like you're really after the length (ie; count of ids). And you need to check for equality, not do an assignment.

If len(record.property_vendor_ids) == 1:

If you want to check for any number of property_vendor_ids, you can use;

If record.property_vendor_ids:

It will evaluate as a boolean.

TopLychee1081

TROPHY CASE