Yes, indeed, some previous worker created the x_ elements.

Sadly, this poses difficult issues for continuing development in Odoo.sh.  The x_ elements exist in the master DB instance and in staging instances restored from the master DB.  That works well.  However, the standard Odoo.sh process of developing and testing new modules/apps in a development branch poses problems as the the x_ and x_studio_ elements from master do not appear in the demo databases used in the standard development builds.

The bottom line is that those elements should have been created in a module if anyone anticipated they would need to participate in future extensions, but they did not.

Alternately, wouldn't it be nice to have a "create or replace" or an "if !exists, create" feature within a module that would allow me to create the x_ or x_studio_ elements in my module, if they didn't already exist, such as in a demo database.  Or perhaps one could use a "bridge" module that is installed only in development containing the elements from master missing from the demo database.

The ideal solution, of course, is to rip out the x_ and x_studio_ elements in the master and replace them with module-derived equivalents.  That's not practical in a running, production system.

In any event, this issue has highlighted for me the problems created by mixing x_studio_ elements with x_ (Settings>Technical) elements and module-derived elements under Odoo.sh.

Hi Ken,

Hope you are doing well.

It seems that the x_producttags model was created in the Odoo Studio, a visual development platform in the Enterprise Edition. It's possible that a previous owner of your system created this model using the Studio, but it is not present in the Community Edition. The x_studio_product_tags field in the product.template model is a many2many relation to the x_producttags model, and it's used to display product tags in forms with the many2many_tags widget.

Team Ksolves!