IDempiere/FullMeeting20130717

From WikiQSS
Revision as of 13:45, 17 July 2013 by CarlosRuiz (talk | contribs) (remove JIRA notifications)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Table of Contents | Full Meeting Minutes | Full Meeting 2013-07-17

hengsin: hi Carlos
CarlosRuiz: Hi hengsin
hengsin: got a question for inventory costing. the costing level is define by accounting schema. if you have multiple accounting schema and have different costing level for the primary and secondary schema, do you know whether that will work ?
CarlosRuiz: checking ...
CarlosRuiz: Hi everybody
nmicoud: Bonjour !
hengsin: hi micoud
CarlosRuiz: hengsin, in cost table there is one record per each acctschema - so it must not be an issue
mhernandezve: Hi all!
hengsin: but you can have conflicting transaction requirement for costing level. for e.g, primary is client and secondary is batch_lot.
hengsin: hi hernandez
CarlosRuiz: yep - still don't get the issue
hengsin: Carlos, I means shouldn't the system disallow such combination ? I means you can't just maintain lot for the secondary schema while the focus should really on the primary
CarlosRuiz: seems like there's something wrong with "Product Costs" window - on demo I can't see the "Cost Details" tab
CarlosRuiz: it would be just that the cost records for second schema are based on lot - and posted via lot
CarlosRuiz: you mean a possible functional accounting issue because the cost values on both schemas can have different amounts?
CarlosRuiz: maybe functionally that can be an issue as your two accountings don't match in inventory valuation
CarlosRuiz: maybe it could be a valid use case - but it will add an extra layer of confusion for the accountants
hengsin: I means transaction wise, you need to do it by lot. if your by lot costing level is at the secondary schema, I don't think the system will validate that
hengsin: anyway, that's just a wild combination that should be rare, just a question of whether the system should allow such level of flexibility.
CarlosRuiz: at this moment I think the system is not validating lot even for first acctschema
xolali: Hello everyone
CarlosRuiz: so, users could do messy things like defining lot cost for a product when the product doesn't have attribute set (which doesn't make sense)
CarlosRuiz: Hi Anthony
xolali: Deepak any news on chart editor feature from adaxa
CarlosRuiz: hengsin, about IDEMPIERE-1168 - do you think as a fix we must not load context of detail tab - just keep in context the master tab?
hengsin: wow, it is even more loose than I've think of.
hengsin: I've not look at that issue, it will be good if we can work with tab context variable instead of master
hengsin: hmm .. for details tab, perhaps just populate by tab only
hengsin: sorry, I means with tab context variable instead of window context variable.
CarlosRuiz: hmm - it's going to be weird if you do changes on master and detail at the same time
CarlosRuiz: at this moment there is something bad with tab context variables
CarlosRuiz: at this moment is dependent on the number of the tab, i.e. @1|Processed@ is the processed field on tab #1 (first tab is 0)
CarlosRuiz: suppose seqno 10 and 20 for master and detail
CarlosRuiz: if an extension introduces seqno 15 - then the tab context @1|Processed@ is broken
CarlosRuiz: it will become @2|Processed@ but the logic will be pointing to the introduced tab
hengsin: for the current UI, detail is visible and editable together with the master tab. I don't think it can work if you totally exclude it from the context
hengsin: perhaps, we can introduce a special notation, for e.g @||Processed@ to means current tab ?
hengsin: or @~|Processed@
CarlosRuiz: also for Processed context variable is in code - not in *logic
CarlosRuiz: and some windows trust in the window "Processed" context
hengsin: yes, that's why I proposed above - only load details tab's value into the "tab context"
hengsin: and if we introduce the @~|Processed@ notation, it solve the change tabno issue too
CarlosRuiz: ah - you mean - global context have the master tab - and detail will be on context as tab variables
CarlosRuiz: that sounds ok
CarlosRuiz: right - will open a ticket also for the @~|Processed@ notation for current tab
Deepak: Anthony, Sorry I was away.
Deepak: patch is in review queue for Carlos
Deepak: So Chart from Adaxa will in iDempiere once Carlos or Low finish his review
CarlosRuiz: is code attached on JIRA? Anthony could help with review too
xolali: ok Deepak thanks. yes i really want to help with the review. am looking at using a different chart library from jfreechart
xolali: an html5 js chart library
Deepak: Anthony, Will upload patch on ticket too. So you can check
CarlosRuiz: hengsin, about IDEMPIERE-883 description mentions that sales flag is not set - but title mention business partner - maybe we change the title to reflect better?
hengsin: no, originally, there is a bug for business partner which have been fixed
hengsin: see the commit history
CarlosRuiz: got it - will open a new ticket then
Deepak: Anthony, please note that IDEMPIERE-1157 has patch in attachment
xolali: yes, just downloaded and checking it out
xolali: thank you Deepak
hengsin: Deepak, is the using id from the original Adaxa migration script or it is using new id generated from idempiere centralized id server ?
hengsin: typo - "is the using" = "is that using"
Deepak: Original from adaxa
CarlosRuiz: is in the range of 50K (adempiere)
Deepak: There was one 2pack committed by adaxa which we convert in migration script. So script to add series column uses iDempiere ID
CarlosRuiz: the changes to AD_Field_V and AD_Field_VT must be on migration script too
Deepak: ohk, Will add that today
Deepak: Can we update original migration script?
CarlosRuiz: I see also all new classes don't have GPL Header - maybe better we ask Steven if he allows us to add them crediting Adaxa properly
Deepak: I will check with Steven
CarlosRuiz: thanks Deepak - will add those comments on ticket and some others too
Deepak: Sure
Deepak: I am working on changing FIFO based DateMaterialPolicy and want to check can I go with assumption that projectIssue line have always ASI?
nmicoud: What do you think of the solution proposed on https://idempiere.atlassian.net/browse/IDEMPIERE-1171 ?
hengsin: Deepak, it is important that all new classes must have the proper gplv2 license header.
hengsin: Deepak, how do you comes to that assumption ?
Edwin_Ang: hi guys.. is there anybody have an idea of https://idempiere.atlassian.net/browse/IDEMPIERE-1170
Deepak414: Low, as we normally need to track asset assigned to project. If any consumable us assign then that can be done using charge
hengsin: Deepak, I don't think you can make that sort of assumption if it is not enforce in the UI.
CarlosRuiz: nmicoud, about 1171
CarlosRuiz: do you mean order the buttons on the gear icon?
nmicoud: no
nmicoud: button added through actions
nmicoud: IAction
CarlosRuiz: ah - to order customized buttons on the toolbar
Deepak414: Low, I looked current code and it never try check for ASI value on line and just create storage entry with that ASI. No logic to get storage for qty in MProjectIssue.process
nmicoud: yes
Deepak414: I am not much familiere with this window and not used ever. So think code may written with that assumption
CarlosRuiz: nmicoud, sounds fine and harmless
nmicoud: ok, will do this then
CarlosRuiz: maybe enable the field seqno when customization=Y
nmicoud: sure, i'll update ticket
nmicoud: btw, any update on ticket 959 ?
CarlosRuiz: ah - sorry Nicolas - what I understood is that 959 is that there are other easier ways to achieve the same without impacting the code so much
nmicoud: i've update a 'lighter' patch last week, with less impact
nmicoud: is it possible to achieve without less modification ?
hengsin: Deepak, any assumption must be consistent with the UI
hengsin: otherwise, your code can get "surprise" at runtime
CarlosRuiz: nmicoud, not sure if we understood 100% your use case - but the conclusion we arrived is that you can do it without changes
CarlosRuiz: your use case is a process/report extension - right?
nmicoud: no
nmicoud: i want to be able to get the UUID of tab, window, process, ... from every core classes
nmicoud: not "every", but main like GridTab...
nmicoud: Actually, i can only test AD_Tab_ID ; i would like to test AD_Tab_UU
CarlosRuiz: you mentioned a customization of trees on the original message - but I still don't get the need :-(
Deepak414: I think I may need to do some study on project issue usage.
nmicoud: i'm customizing a window which will have some trees. It needs to customize GridTab, MTree, ... And i need to identify the current tab to show correct datas in my trees
nmicoud: I would like to get the UU as it will always be the same (thanks to 2Pack) instead of ID (i won't use centralized ID)
CarlosRuiz: _TabInfo_AD_Tab_UU context variable?
nmicoud: i need it in code ? Are context variable available in code ?
CarlosRuiz: yep - if the code is related to a window
CarlosRuiz: if you have the windowNo (which usually you have) you can get the context of that window
nmicoud: with something like : string uuid = Env.getContext (Env.getCtx(), getWindowNo(), _TabInfo_AD_Tab_UU); ?
CarlosRuiz: no, like this
CarlosRuiz: string uuid = Env.getContext(Env.getCtx(), WindowNo, TabNo, "_TabInfo_AD_Tab_UU");
CarlosRuiz: as tab_uu is a tab context variable you also need the tabno
nmicoud: that's better :)
nmicoud: ok, then i will test this
nmicoud: thanks
CarlosRuiz: Edwin_Ang, checking 1170
Edwin_Ang_: CarlosRuiz: thanks.. any hint about it?
CarlosRuiz: ah - after inserting the nodes are not draggable
Edwin_Ang_: yes.. it is causing issue for me cos i also use a tree on my project window
CarlosRuiz: you said it worked on 1.0b
CarlosRuiz: trying to find changes to tree ... and checking the behavior without that change
nmicoud: Seems to be related to itemDraggable (from SimpleTreeModel) ?
Edwin_Ang_: yes.. cos i reverted to 1.0b and tested it
Edwin_Ang_: it's working
Edwin_Ang_: just checking the changeset
Edwin_Ang_: probably related to IDEMPIERE-1060?
CarlosRuiz: I'm trying to test reverting that changeset
CarlosRuiz: yes Edwin_Ang_
CarlosRuiz: reverting that changeset works
CarlosRuiz: Edwin_Ang, reverting that changeset works - so now will try to find the line with the problem
Edwin_Ang: ah.. thx Carlos
xolali: Carlos, were u able to aply the patch from Deepak, am getting a abort:bad hunk #1 error
CarlosRuiz: ah - I applied it into release1 branch from trekglobal repo - is a little ahead as there is where hengsin and I are making peer review before integrating to idempiere
CarlosRuiz: I mean this one https://bitbucket.org/trekglobal/idempiere
xolali: ok, will check it from there
nmicoud: do you know when you'll be able to integrate things from the peer review queue ?
CarlosRuiz: I am - slower than before, but I am :-)
nmicoud: :))
CarlosRuiz: slower because I'm more focused on testing nowadays
nmicoud: stabilize and then integrating new stuffs (and bugs ;))
CarlosRuiz: :-)
Edwin_Ang: well.. it is one package right.. feature and bugs
Edwin_Ang: :D
nmicoud: lol
Edwin_Ang: btw.. nicolas.. do you have any idea to set the itemdraggable value dynamically?
Edwin_Ang: in my case
Edwin_Ang: my window is has two tabs
Edwin_Ang: first one is project
Edwin_Ang: second one is project activity
Edwin_Ang: i want to set the itemdraggable value to false when the project status changed to some value
Edwin_Ang: any ideas?
nmicoud: yes
nmicoud: in ADTabpanel, on dataStatusChanged, you can see if you value ahs changed and then try to change the itemdraggable to false or true
nmicoud: SimpleTreeModel model = (SimpleTreeModel)(TreeModel<?>) treePanel.getTree().getModel();
nmicoud: model.setItemDraggable(true/false);
Edwin_Ang: however i want to use value on the parent tab to control the tree
Edwin_Ang: project status is on project tab
Edwin_Ang: while my tree is on project activity
nmicoud: means that child tab can be draggable or not ; depending in master value ?
CarlosRuiz: ok - the guilty is the if added on ADTreePanel.initTree
Edwin_Ang: yes
Edwin_Ang: i have several project status
Edwin_Ang: when the status is Initiating / Planning, user will be able to change the tree freely
Edwin_Ang: is the status is Executing / Monitoring / Closed, the tree cannot be dragged anymore
nmicoud: so, perhaps, you can do something like this in dataStatusChanged or perhaps in activate
hengsin: Carlos, removing that will caused different problem though
nmicoud: gridTab.getParentTab().getRecord_ID() => and then look for the status, and then update itemdragable value
Edwin_Ang: just want to make sure.. are all fields in a tab recorded as context variable?
Edwin_Ang: i am thinking of adding in SimpleTreeModel initADTree
CarlosRuiz: hengsin, analyzing - the treemodel changed after new record and the new treemodel is not draggable - finding the cause
CarlosRuiz: yes, all fields are context
Edwin_Ang: can i do something like this?
Edwin_Ang: String status = Env.getContext(Env.getCtx(), windowNo, "ProjectStatus");
Edwin_Ang: if (vTree.getTreeType().equals(MTree.TREETYPE_ProjectActivity) && (status.equals("IN") || status.equals("PL")))
Edwin_Ang: { treeModel.setItemDraggable(true); }
hengsin: carlos, the test is correct if it is update so I guess that's where it need to be improved upon.
CarlosRuiz: seems like is ADTabpanel.dataStatusChanged
CarlosRuiz: hengsin, ADTabpanel.dataStatusChanged line 1220
CarlosRuiz: is creating a new model repeatedly - on each data status change - for example on new - or updating the first field
CarlosRuiz: and this created model is not set draggable and listening dropevent as in initADTree
CarlosRuiz: that code was added for IDEMPIERE-950 - maybe we need to change it to call initADTree - let me check
CarlosRuiz: yes - got the patch
CarlosRuiz: Edwin_Ang, patch is here if you want to test -> http://bitbucket.org/trekglobal/idempiere/commits/1bce93d
CarlosRuiz: will move into iDempiere after hengsin's approval too
Edwin_Ang: ok thanks
Edwin_Ang: will test it
nmicoud: gtg ; bye bye
Edwin_Ang: gtg now
Edwin_Ang: carlos thx for the patch
Edwin_Ang: it is working
Edwin_Ang: will do more test to confirm
CarlosRuiz: excellent - thanks
Edwin_Ang: bye