Add a comment field on Bank Account; because description is used to in invoices.
git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@23554 20353a03-c40f-0410-a6d1-a30d3c3de9de
-
Developer@jerome, I noticed that
Bank Accountdoes not haveCommentProperty Sheet, so this creates local properties.Easy fix is to add it in. But, I was wondering, would it make sense to add
Commentto a more basic level (Base ?)?Generally, for
descriptionand otherDublinCoreproperties I think it is done somehow here, but did not check exactly how it works. -
Owner
@georgios.dagkakis mmmh I don't know, here are some random thoughts on the topic:
Dublin Core is a specification of document metadata and there is no comment field in this spec ( I just searched for "comment" in http://www.dublincore.org/specifications/dublin-core/datamodel/ ) I believe it would not be correct to "extend" dublin core in ERP5 with comment.
If I were you I would just add the property sheet on
Bank Accountportal type (or maybe on aNodeclass), for simplicity and also because adding it at a lower level would be against this idea of organising the data model in different layers of property sheets - like "we could just put everything in Base and don't have property sheets".On the other hand, we can potentially comment on every document.
There was also recently this idea that "every document is discussable" so that we could start using something like a ticket and web messages (in a way similar to support request app) everywhere, so that we accountants could discuss "why did you record that invoice 10 years ago" directly on the invoice just like we developers are discussing "why did you made this change 10 years ago" directly on the commit ;-) that's not really "comment", that's "discussion" but it's very similar.
-
Owner
Thanks for catching this BTW. I think that if we just add the property sheet, the
getCommentaccessor would pick up the local property and no data migration or anything would be needed. -
Developer
I agree we should not mingle with Dublin Core extending ourselves.
But I disagree with adding it at a lower level would be against this idea of organising the data model in different layers of property sheets - like "we could just put everything in Base and don't have property sheets".
For me comment (like description, title, reference) is something that can semantically apply to every ERP5 Type. So what I propose is not in the same level like e.g. saying 'let's put price to everything'.
I think that if we just add the property sheet, the getComment accessor would pick up the local property and no data migration or anything would be needed.
Yes, getter works. We still see in
Base_viewDict:_local_properties : ({'id': 'comment', 'type': 'string'},)but I think it is no issue
-
Owner
For me comment (like description, title, reference) is something that can semantically apply to every ERP5 Type. So what I propose is not in the same level like e.g. saying 'let's put price to everything'.
Yes, that really makes sense.
Also, I don't think there are many arguments for "if you want to use comment on some document type you must absolutely associate the portal type with Comment property sheet, otherwise it would still work the same but just create local properties"
-
Edited by Tatuya Kamada
@georgios.dagkakis Thank you let me know this topic.
I have a responsibility on Interface of ERP5, but I could not work on it in reality. Only Georgious and a few folks reminds me this sometimes :-)
Here are my points on interface:
- Flexibility is important [flex]
- (from erp5.com: Its innovative Unified Business Model reduces complexity of configuration and increases flexibility.)
- Interface should be minimal [min]
- If you familiar with math, imagine the algebraic structure (ring, field, group, etc,.) https://en.wikipedia.org/wiki/Algebraic_structure
- If you familiar with C++, imagine the design of STL library (http://stepanovpapers.com/STL/DOC.PDF)
- Fewer file system staffs is the future by ZODB components [fs]
- Explicit is better than implicit (from The zen of python https://www.python.org/dev/peps/pep-0020/) [exp]
Based on the above points, my opinion on this topic are:
- Should not add comment property into DublinCore property sheet ([min] and as Jerome pointed out)
- Should not add Comment property sheet into Base.py class. ([flex],[min],[fs])
- I am sure we can not comment all the Document. Note that ERP5 documents represents a Paper document by its initial design.
- So a counter example: a read-only document (such as a constitution, or a law)
- We can add Comment property sheet into Bank Account or Node portal type definition (in erp5_core business template)
PS. It's a coincidence, and it's an another story, but I recently have a issue of a DublinCore property : title. Since it is the only Acquired Property in DublinCore, and due to this fact(it seems), it behave differently on ERP5 listbox user interface than ERP5 catalog brain.
- Flexibility is important [flex]
-
Developer
Thank you @tatuya for this information.
I added it directly to
Bank Accountin 75b5c827. For me intention was to fix this specific problem (having comment in the view, but no Property) or check if we could have some generic addition in all types. Since the latter is not advised, I preferred to do the minimal fix.PS. It's a coincidence, and it's an another story, but I recently have a issue of a DublinCore property : title. Since it is the only Acquired Property in DublinCore, and due to this fact(it seems), it behave differently on ERP5 listbox user interface than ERP5 catalog brain.
You mean searching for it by listbox may not find it if it is Acquired, but, if we do have the document listed, Listbox will display it?
-
Edited by Tatuya Kamada
@georgios.dagkakis Thank you for your great effort!
You mean searching for it by listbox may not find it if it is Acquired, but, if we do have the document listed, Listbox will display it?
Probably yes. The fact I found recently is the following:
Let the listbox column be
title | Title.- If a list method returns
[x for x context.portal_catalog(portal_type='Sale Order')], the title is displayed. - If a list method returns
[x.getObject() for x in context.portal_catalog(portal_type='Sale Order')], the title is not displayed.
- If a list method returns
-
Developer
Let the listbox column be title | Title.
- If a list method returns [x for x context.portal_catalog(portal_type='Sale Order')], the title is displayed.
- If a list method returns [x.getObject() for x in context.portal_catalog(portal_type='Sale Order')], the title is not displayed.
But do those Sale Orders have title property? I feel the case is that they acquire from reference, so hasTitle gives False, while getTitle gives the reference value. Then, in indexation we use something like
getTitle[loop_item], which would index the reference value. This is why if we return catalog result, title column works. But if we return objects, it does not.Can this be the case? If yes, it is not related to DublinCore I believe
-
@georgios.dagkakis Thank you very much for your investigation.
If you are sure, you are right. However even if your are right, I am still not sure why it does not displays the title, because sale_order.getProperty('title') acquire the title from the reference.
I will come back this topic when I can allocate some time on it. (The original intention on this is to optimise the speed of the module views, because returning the Documents to the listbox is a bit faster than returning brains)
