I am implementing a multi-company project and noticed that several models in the payroll modules are missing the company_id field.
Is there any official documentation explaining what would be the behavior of Odoo's multi-company environment
when company_id is not defined in a model?
I made some tests...
When I created records from these models, I noticed two different behavior.
On one occasion the record was shared between companies (as if there were a company_id field set to false).
On another case, the record is not visible outside the company from where I created it.
Thanks
Related
I am trying to learn domain modeling , now lets consider a shopping cart example.Lets user can browse catalog of products and add products to shopping cart, purchase those products.To purchase products he will place order.User can trace his order details.He can call up customer rep to know about status of his order.
Please validate my Domain model in full scope.
Below is Domain Model i have designed , i am having issues in representing order and order status what is the right way to do
How would i link product and order.
A (conceptual) domain model is a solution-independent description of a problem domain produced in the analysis phase of a software engineering project. It may consist of information models (typically in the form of UML class diagrams), process models (typically in the form of BPMN diagrams), and possibly other types of models.
A domain class model contains only conceptual elements, such as properties (possibly without datatypes) and associations. It does not specify the visibility of properties and methods, as visibility is a platform-specific concept.
Your model is incomplete in many respects (e.g. it does not describe order lines/details, which are taken from the cart), and it does not contain any association. Clearly, an order is associated to one customer and to many items/products (via its order lines).
OrderStatus should be modeled as an enumeration, which is a UML datatype that is stereotyped with <>, and Order should have a status attribute with this enumeration as its range.
The model below may be a bit more general than what you had in mind, because it allows for several warehouses from which an order item can be sourced, and it also distinguishes between private and corporate customers.
You can make "order details" an associative class for the relationship between order and product. See the example:
IBM example of an associative class
Note that yours is really a class diagram. A domain diagram shows the dependencies on different problem domains such as
Order fullfillment
Database
RemoteCommunications
SystemMaintenance
etc.
I am new to openerp I came across res.partner but I couldn't understand what it does and what all functionalities it provides,so if anyone could explain it to me I would be grateful.
To clarify.
res.partner is an ORM Model. An ORM model describes a class of objects in the database and provides a series of ORM methods to allow you to manage them in code (create, write, unlink etc).
To get the database table, unless there is a specific _table override, just convert the periods to underscores so the table in the database is res_partner. As with any "res." model, you get res.partner as part of the core of OpenERP rather than any additional model such as accounting or sales.
But to answer a wider question, what is res.partner for in OpenERP? Assuming OpenERP 7, res.partner contains information about any entities you have a relationship with.
This includes:
Customers - you have a res.partner entry for each customer plus a res.partner entry for each contact person or address (invoice to, deliver to) you set up for that customer.
Suppliers - same as customers. In fact, the only difference between the two is a boolean field on res.partner to say if they are a customer or supplier.
Users - each user allowed to log in to your OpenERP instance has a related res.partner to store address details.
Companies - each company you set up in OpenERP assuming you are using multi-company has a related res.parter to store address details.
res.partner is the technical name for the Model representing Partners:
Partners represent People and Organizations.
The most straightforward example are Customers and Suppliers.
Other examples of Partners are:
Contact persons within an organization
Customer or Supplier Adresses
Employees personal contact data
Users contact data
So it's a base concept used pretty much everywhere in the application.
Two resources:
/user
/product
The database table name is user_product and it describes relation between user and product. However, endpoint POST /user/{id}/product/{id} would indicate updating a specific product under user, as opposed to creating a new relation.
I have therefore named the resource POST /user/{id}/product/{id}/purchase, which defines fictional resource purchase. After all, this is what the data in the table represents.
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
I would guess that your purchase is stored in a database somewhere and the actual purchase assigned its own ID. Why not use that ID directly as in /purchases/{purchase-id}?
Your example /user/{id}/product/{id}/purchase won't work if one user has more than one purchase of the same product. Unless of course the resource either signals "The user has at least one purchase of product X" or returns a list of all purchases of product X for that user - which looks more like a query (which is fine to assign its own resource).
I have therefore named the resource POST /user/{id}/product/{id}/purchase.
Please be aware that you don't include method names (like POST) in resource names. And why the POST? Is it for creating/modifying the relation - or did you mean GET to get some information about the relation?
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
No, but if you want some hints then I wrote a piece on this subject here: http://soabits.blogspot.dk/2013/10/url-structures-and-hyper-media-for-web.html
I have a rails app that includes tagging for blog posts using the gem acts-as-taggable-on. My idea is to extend the tagging mechanism of this gem using a moderate-link approach where I can choose to create a few users as tag owners and they can choose to link one tag to another as parent/child.
Presently the system has independent tags like Education, Child Education and Distance Education
The tag owner of Education can choose to select Child Education and Distance Education
as first level child and link them together. This relationship wont be visible until its approved by the Taxonomist(A tag administrator).
Similarly, an end user can also suggest Distance Education tag to be the child of Education and this request will become visible to the tag administrator. Based on his approval the relationship will be established.
These are the few questions I have pertaining to the requirement above:-
Is it recommended to extended the gem or should I use an independent tagging model written from scratch to support this hierarchical system ?
If I go ahead with the schema provided by the gem , what kind of a model should be used to design such a requirement. Specifically, should I use a single table with a parent_id column with the tag id and tag name ? Or should I maintain their relationship in a separate table with many-to-many associations (tag_id, parent_tag_id (as Foreign key)).
I am also new to data structures so I will need some initial inputs on the choice of algorithms to efficiently traverse between a tag family. Using linked list was one my options however considering Rails mantra of convention over configuration , I am really unsure of how to proceed on this.
I remember doing something similir like 4 years ago with ActsAsTree.
There s also an example of how to do it manually here.
Both options will need that parent_id column on your tags table and are really straightforward. Just create a tag.rb in your models folder and extend Tag class.
Ps. Its been a long time, but i remember having to check that there are no loops, just keep it in mind
I am new to this, so my understanding is still flaky.
I have a Person model and an AccountType model in my project. Each person references an account type.
Now if my understanding is correct a Person is definitely an aggregate root, whereas the AccountType probably isn't as the entries in the account type table are going to be pretty much static and are certainly have no meaning outside of a Person.
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
What would be the correct way to structure this?
I think that AccountType is another aggregate root which is referenced from the Person aggregate root.
It's absolutely normal to have many simple aggregate roots, see Vaughn Vernon articles, see part 1, p. 5:
On one project for the financial derivatives sector using
[Qi4j], Niclas [Hedhman] reported that his team was able to
design approximately 70% of all aggregates with just a
root entity containing some value-typed properties. The remaining 30% had just two to three total entities. This doesn't indicate that all domain models will have a 70/30 split. It
does indicate that a high percentage of aggregates can be
limited to a single entity, the root.
In your question it's not quite understood, what is the problem with accessing repositories to initialize the aggregate root's properties:
However when I create a new person I need to set the account type, so it would seem I need a repository to access the account type to assign to the user, but the repository code I have only allows aggregate roots to be accessed.
The initialization of the Person class should be handled by PersonFactory.
The PersonFactory is a service, so it can have reference to AccountTypeRepository to find a suitable AccountType instance and return a fully constructed Person instance of that type.
update: Also I'd like to add a note that referencing your AccountType by id works equally well. It's all matter of convenience, sometimes it's more convenient(only for displaying, not for modifying, of course) to access the references directly if you use GUI frameworks with rich data binding capabilities like WPF or Spring MVC so you can directly access this properties to display in View. If you are using the id approach, this may force you to create ViewModels (FormBeans) even for the simple Entities.
Regarding the lookup-based solution, it works well for very simple enum-like fields, I suppose that AccountType is something more complex than that and belongs to the knowledge level (see the discussion of the question).
Returning to the choice between aggregates and value object(also see this), it depends on the abstraction level and configuration capabilities of your information system.
From the point of view of the Account class it may look like a value object, you can replace one AccountType with another: it will be just like switching between Color value objects, but from the point of the knowledge level your user may want to customize the behavior of the system for selected AccountType, for example change discounts for specific "Premium" accounts. So if you have the knowledge level, AccountType will be something with an identity which leads you to creating a separate repository.
The most important thing is (assuming AccountType has an entity with an ID and is not a simple enum)...
Account Type and Person should only reference each other by ID.