From WikiQSS

Table of Contents | Full Meeting Minutes | Full Meeting 2013-12-18

NOTE: This time full log will preserve the JIRA notifications (Not-002) as this meeting was dedicated to triage, so the JIRA notifications are integral part of the meeting purpose

tbayen: nmicoud, I use these all for some time and tested them. (the last one only for some days) Perhaps you can have a look and give a comment if we recommend Carlos to insert them.
CarlosRuiz: Good Morning
nmicoud: ok tbayen, will do this
nmicoud: Bonjour !
tbayen: bhoot, AFAIK there is no advantage of JTA to normal transactions if you use only one database.
tbayen: Daarestiet, Carlos!
tbayen: bhoot, you said "guten morgen" - are you german?
CarlosRuiz: so, today is intended for triage old JIRA tickets?
nmicoud: i think yes
bhoot: I am indian. There are many german in room.
tbayen: ok :)
CarlosRuiz: also for those old that we want to be included - we could vote
tbayen: The oldest one on my personal list is IDEMPIERE-603. I would just close it. It is assigned to hengsin , WDYT?
nmicoud: ok for voting
CarlosRuiz: you mean export BP via 2pack is not exporting the location?
tbayen: yes. I am no more interested in this, noone else was interested in this in the last 10 months and the Importer solves this kind of issues well.
hengsin: +1 to close it :)
CarlosRuiz: is it possible to move not-evolved ideas to another platform?
CarlosRuiz: we can use those ideas for example for GSoC
tbayen: The issue is still there. Perhaps we can close it and set a label if you think it could be of use later.
nmicoud: later... not sure ; i fear it means never, no ?
CarlosRuiz: :-) I read a joke, something like the scale of time of a developer is: tomorrow, next week, next month, next year, and TODO
tbayen: The length of the actual issue list shows the meaning of "later". :-) Bugs are solved in three weeks or never.
CarlosRuiz: tbayen, maybe a label like "Potential-Idea" - so, if we get GSoC sponsorship we could collect them
CarlosRuiz: close it and label as Potential-Idea if is worthy to develop some day
tbayen: ok. Do you think IDEMPIERE-603 is a "Potential-Idea"?
CarlosRuiz: yep
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-603 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
nmicoud: perhaps the status should also set to something else that 'open' ?
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-603 status set to "Closed" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
CarlosRuiz: and we close it as "Won't fix" resolution?
CarlosRuiz: :-) you're faster
nmicoud: :D
CarlosRuiz: IDEMPIERE-143 can be closed also I think - it was a collection of performance improvements
hengsin: tbayen, I guess you can create a section at the wiki for "ideas" ...
tbayen: yep, I will do that.
Not-002: [IDEMPIERE] hengsin updated IDEMPIERE-143 status set to "Closed" -assignee set to "Heng Sin Low" -Fix Version set to "release-1.0c" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
tbayen: 1:1
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-136 labels set to "Potential-Idea base language"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-136 status set to "Resolved" -resolution set to "Fixed"
Not-002: [IDEMPIERE] Potential-Idea -> Pending TODO: VerifyLanguageConfiguration
Not-002: [IDEMPIERE]
tbayen: What about IDEMPIERE-615? I find it useful in my environment. But if we think it to the end we have to change many points in code. Is it worth to do this? WDYT?
hengsin: don't use windows :)
tbayen: I have this issue on linux on a terminal server installation.
hengsin: AFAIK, for linux server, /tmp is usually auto clean periodically
tbayen: Hmm... seems this is a swing issue.
CarlosRuiz: or you can schedule a cleaner
CarlosRuiz: in ubuntu is cleaned on reboot - but you can schedule it
CarlosRuiz: also I think the permissions could be set using umask
CarlosRuiz: tbayen, as you said is swing - maybe the umask of the user running idempiere can be set more safe
tbayen: The systems I know of do not schedule a clean of /tmp. They do it just when rebooting. But you do not need to reboot a linux system very often...
tbayen: My issue was not so much about security but about very many temporary files staying in the directory for a too long time.
CarlosRuiz: seems like is there for centos/fedora - but not for ubuntu
CarlosRuiz: but 100% of chance there is an ubuntu version
tbayen: I thought the cleaner way is to use deleteOnExit(). But I see you do not agree. I accept I am overruled by you and will comment on this issue and close it.
hengsin: calling deleteOnExit does add performance overhead and could be an issue on long running server
tbayen: I think we could say that deleting a temporary file from outside (e.g. cron) that is older than one hour or more is always safe.
hengsin: "The implementation of simply keeps a list of String representing all the files that need to be deleted when the VM exits".
ocurieles_DCS: Good Morning Friends...
CarlosRuiz: and it won't work if the JVM is killed with -9 or thread is broken because of memory
CarlosRuiz: Hi Orlando
aguerra: some idea ...
CarlosRuiz: seems like I cannot vote for my own tickets - I have a partial implementation of IDEMPIERE-149 - but haven't found the time to finish it - maybe for R3
CarlosRuiz: interesting aguerra - didn't know about TMPTIME variable - sometimes I would like to preserve some ongoing tmp files after a crash
ocurieles_DCS: we are working to integrate RFid Technology to iDempiere, Specially for fixed assets, maybe for R3 Too :D
CarlosRuiz: found the package on ubuntu -> tmpreaper
CarlosRuiz: ok to close IDEMPIERE-102 and point to the LCO_DetailedNames plugin?
nmicoud: yes
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-102 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed"
Not-002: [IDEMPIERE] Implemented as plugin:
Not-002: [IDEMPIERE]
aguerra: much better @CarlosRuiz, ---> tmpreaper
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-615
Not-002: [IDEMPIERE] We talked about this in the today meeting. The security issue is not a big issue in most environments. The problem of the uncleaned tmp directory is not best solved with deleteOnExit(). This uses Java resources and does not work if the JVM is killed for some reason: servers are often killed, memory leaks, etc. It is also not a good solution for long running servers. So this is mostly a swing issue. A better solution is to clean the tmp dir
Not-002: [IDEMPIERE]
CarlosRuiz: IDEMPIERE-166 -> rebranding - is it pending? potential-idea? or done?
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-615 Component set to "Swing Client"
Not-002: [IDEMPIERE]
hengsin: I think we will need to rethink on field arrangement for extensions. the use of seqno doesn't work well since extensions can all compete for the same seqno.
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-615 status set to "Closed" -assignee set to "Thomas Bayen" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Workaround with cron is a better solution.
Not-002: [IDEMPIERE]
CarlosRuiz: idea from JJ is that official fields have a multiple of 10 seqno - and extension field are put in the middle
CarlosRuiz: usually we have problems when migrating as the seqno of many fields can be moved - and then your intermediate fields are wrongly positioned
hengsin: I think we can close 166 and open new ticket if we need to make other changes
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-166 status set to "Resolved" -assignee set to "Heng Sin Low" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
hengsin: it will be a mess if we did have many plugins. imaging 3 or more plugings that all want to insert fields between 10 and 20
CarlosRuiz: nmicoud, IDEMPIERE-257 potential idea?
nmicoud: i think it still can be done (honestly i do not remember of this one). Could be a common requirement ?
nmicoud: as i will probably need it in the next few months
nmicoud: i could then upload a patch
CarlosRuiz: could be also solved extending the concept of SysConfig to User - I have thought in past that there are sysconfig keys that can go down to role and user
tbayen: nmicoud, if you need it we can keep this open. If noone needs it I would close it as Potential-Idea.
CarlosRuiz: actually is System/Client/Org - could be System/Client/Org and another path for System/Client/Role/User
nmicoud: means users can go in the SysConfig window ? could be dangerous, no ? and they will never understand how it works. The 'my profile' window is better no ?
CarlosRuiz: means the IT support guy can go to SysConfig and configure it for the user
tbayen: I would not do this configurable by user. But the idea to configure things in the sysconfig by role may make sense.
hengsin: so system/client/role will win over system/client/org ?
hengsin: or you wouldn't have both at the same time ?
CarlosRuiz: no
CarlosRuiz: when you create a sysconfig key you define the scope
CarlosRuiz: scope at this moment is System/Client/Org
CarlosRuiz: we would add Role and User - but I think those are not compatible with Org - so we create another path for discovering these two -> System/Client/Role - and System/Client/User - depending on the scope
CarlosRuiz: it sounds probably not too intuitive - maybe we would be adding a not so good idea - maybe a better management of Preferences can solve better the issue
hengsin: I think the issue of adding system/client/role or system/client/user scope is it could make thing very hard to manage or understand. when things doesn't work as expected, you now have another variable to worry about.
tbayen: This becomes a totally new issue. :-) (Bad progress for the triage but good for the project.)
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-267 labels set to "Potential-Idea base"
Not-002: [IDEMPIERE]
hengsin: and it is a flat list now with no enforce naming convention and no datatype validation
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-267 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Potential-Idea - create the movement and check the period against the Login @#Date@
Not-002: [IDEMPIERE]
nmicoud: so - about 257 - i will upload a patch "later" and you decide if it can be integrated or not (but i think it will use the AD_User table)
Not-002: [IDEMPIERE] nmicoud updated IDEMPIERE-257 assignee set to "Nicolas Micoud"
Not-002: [IDEMPIERE]
CarlosRuiz: nmicoud, can the notificationtype be used?
CarlosRuiz: just asking -not analyzed
hengsin: I agree it is probably good for the project to add more configurable system config flag but I think at some point, we need to make this more usable and more manageable.
nmicoud: is also used for being notified by the system
nmicoud: 257 is only here to answer the question "do you want to receive a copy of the mail you sent through idempiere ?"
tbayen: I like the idea of IDEMPIERE-102 and do not think this should be solved as a plugin but in core. Perhaps this depends on my native language's habits. If you want to close it now I would like to set it on the Potential-Idea list.
tbayen: I created a filter and a wikipage:
hengsin: isn't there's the concept of middle name too ?
CarlosRuiz: nmicoud, I think the SEND_BCC appeared because google apps and thunderbird (or an external mail tool) - the mails that you sent from idempiere didn't appear on your thunderbird
CarlosRuiz: if you can configure it by user I think the sysconfig key becomes useless
tbayen: In german we sometimes need the firstname and sometimes the lastname. The problem is that the correct name for a document is "FL" but for sorting reasons the "Name" field contains "L, F".
nmicoud: yes, ad_user table seems ok for that purpose (and it can be set next to the email adress for instance)
CarlosRuiz: in the LCO_DetailedNames the "L, F" or "F, L" is configurable
CarlosRuiz: the comma is configurable too
CarlosRuiz: and for countries that don't use the 4 names (like USA) - but use the middle name - then FirstName2 could be renamed to Middle
nmicoud: sorry, but what is middle name ?
CarlosRuiz: hengsin, IDEMPIERE-231 can be closed? now you're working on zk7
tbayen: I like how the lco plugin does it. I think this is woth to include in core.
Not-002: [IDEMPIERE] hengsin updated IDEMPIERE-231 status set to "Resolved" -Fix Version set to "release-1.0c" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
hengsin: ok, done. will open new ticket for new improvement in future.
nmicoud: if 102 included in trunk, i would suggest that AD_User should also get those fields
nmicoud: and thanks for the link
nmicoud: but i did not see clearly the difference between firstname 2 and middlename ; probalby a vocabulary issue
CarlosRuiz: yep - I think is the same
aguerra: mnicoud, middle name, ej: Alejandro Jesus ----> Jesus is a middle name
CarlosRuiz: "In Canada and the United States, such names are specifically referred to as middle name(s); in most European countries they would simply be regarded as second"
nmicoud: ah ok, i though you were saying there was a difference :D
nmicoud: i was looking for it
CarlosRuiz: so, is solved by translation :-)
nmicoud: yes
tbayen: I think you can configure this by the business partner language. the lco plugin seems to use a document type for this.
CarlosRuiz: IDEMPIERE-235 can be considered a bug - is rare - and it requires some discussion or make it configurable
CarlosRuiz: must we close it as potential-idea - or keep it open (as a bug)
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-228 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-228 status set to "Resolved" -resolution set to "Fixed"
Not-002: [IDEMPIERE] Potential-Idea: worthy to integrate as plugin?
Not-002: [IDEMPIERE]
nmicoud: i haven't study it but 228 has the same purpose as 2Pack ?
CarlosRuiz: yep - and 2pack is more powerful
CarlosRuiz: can be worthy just if we plan to integrate things from Adaxa that are contributed that way
CarlosRuiz: but there are also other ways to achieve the same
CarlosRuiz: about IDEMPIERE-164 ? swing POS ? seems like it is unmaintained and not used at all
nmicoud: i do not use it so no problem for closing it
CarlosRuiz: ah no - my fault - POS is working - with GardenUser - with GardenAdmin it's not configured
hengsin: 228 is intented to replace migration script
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-164 labels set to "POS Potential-Idea SwingUI"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-164 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] > Swing POS require deeper review on iDempiere - in my local tests is showing a blank window Tested again - seems to be working with GardenUser but not configured for GardenAdmin. Potential-Idea: deep review of POS and make it work - at this moment seems like unmaintained
Not-002: [IDEMPIERE]
CarlosRuiz: hengsin, IDEMPIERE-167 Potential-Idea?
hengsin: yes, potential-idea
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-269 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Triaging old JIRA tickets -> could be solved on BP Window as a virtual column - and on Info BP as a new column
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-167 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-167 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-304 status set to "Resolved" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-315 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-315 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Potential-Idea: to integrate in payroll plugin
Not-002: [IDEMPIERE]
CarlosRuiz: nmicoud, IDEMPIERE-349 ? swing issue 511 days old
nmicoud: it can be dealt by the SMT ?
Not-002: [IDEMPIERE] longnan updated IDEMPIERE-228
Not-002: [IDEMPIERE] Not too much for now, it looks no new update from adaxa for ad_migration recently. some features have been provided by ODT plugin
Not-002: [IDEMPIERE]
CarlosRuiz: hengsin, IDEMPIERE-360 seems outdated - the patch doesn't apply to actual MANIFEST
CarlosRuiz: also - I think IDEMPIERE-361 is a potential idea - but didn't evolve
hengsin: yes, the patch for 360 is outdated
hengsin: Jeroen have never confirm whether it works either
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-360 labels set to "Potential-Idea"
hengsin: 361 is just a potential-idea, never have plan to integrate that
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-360 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-361 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-361 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
hengsin: 360 is plan but probably 1 or 2 release away
CarlosRuiz: tbayen, IDEMPIERE-278 - potential idea 569 days old?
tbayen: mom... hava a call here
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-362 status set to "Resolved" -resolution set to "Fixed"
Not-002: [IDEMPIERE] Probably there are still some pending unidentified things to hide - but closing this on triage session as the intended work is complete.
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-372 status set to "Resolved" -assignee set to "Carlos Antonio Ruiz Gomez" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-381 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] The info windows are now configurable - so, this can be set per implementation preference
Not-002: [IDEMPIERE]
CarlosRuiz: hengsin, can we close IDEMPIERE-405 ? or is ongoing?
Not-002: [IDEMPIERE] hengsin updated IDEMPIERE-405 status set to "Resolved" -Fix Version set to "release-1.0c" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-411 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
hengsin: ok, closed
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-411 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Potential-Idea: cash journal implemented as extension
Not-002: [IDEMPIERE]
CarlosRuiz: SMT -> IDEMPIERE-412 475 days old :-)
nmicoud: yep ; i will see with tbayen if we do it or not
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-416
Not-002: [IDEMPIERE] Maybe we can analyze this from the PostGIS perspective as a plugin?
Not-002: [IDEMPIERE]
nmicoud: what is PostGIS ?
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-418 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Distribution Order not on core
Not-002: [IDEMPIERE]
CarlosRuiz: ah - you're on oracle :-)
nmicoud: yep :)
CarlosRuiz: guys, I need to go out for a meeting - will be back in 1h
CarlosRuiz: or less hopefully
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-441 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-441 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Potential-Idea: can be implemented using database specific tools. Like postgresql text search: And oracle:
Not-002: [IDEMPIERE]
CarlosRuiz: hengsin, WDYT about IDEMPIERE-424? is that being worked? or a potential idea?
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-432 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-432 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
tomtanaka: Hi there.
CarlosRuiz: Hi tomtanaka
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-454
tomtanaka: I have one question regarding iDempiere. Is it possible to create something like SalesForce's sanbox and create a separate database?
Not-002: [IDEMPIERE] Development of this feature is complete - I would suggest to close this ticket as fixed and open specific tickets for areas of improvement.
Not-002: [IDEMPIERE]
hengsin: 424 is just potential-idea.
hengsin: no movement thus far
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-424 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-424 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-456 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-456 status set to "Resolved" -assignee set to "None" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
tbayen: Hello, I am back - sorry
tbayen: nmicoud, did you ever look into the swing pos?
nmicoud: nope
nmicoud: and i fear i will never
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-444 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-444 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Triaging as not needed after 447 days - as the workaround is the most used case mostly nobody notice this, marking a potential idea in case we want to fix it later.
Not-002: [IDEMPIERE]
tbayen: Before closing 164 I would like to hava a look on the whole thing. We should not decide to close bugs about it when it is still active in some kind. Or we accept to abandon the whole POS.
CarlosRuiz: hengsin, IDEMPIERE-434 has a comment from you - is that planned or potential-idea?
CarlosRuiz: tbayen, IDEMPIERE-164 is open for 668 days - indication that nobody cares about - so I think is just a potential-idea in case somebody wants to use it later
tbayen: CarlosRuiz, IDEMPIERE-278 is still in my mind. It is part of a rework of JasperReports. There are some things that can be improved. We can let it open or consider it as an Idea. WDYT?
CarlosRuiz: I think is an idea - you can reopen it later if you evolve it
CarlosRuiz: ok - now my meeting is finally starting :-) brb
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-278 labels set to "Potential-Idea report"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hengsin updated IDEMPIERE-434 status set to "Resolved" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hengsin updated IDEMPIERE-434 labels set to "Potential-Idea"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-278 status set to "Closed" -assignee set to "Thomas Bayen" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] This issue is open for a very long time and I close it now. This should be thought new if someone wants to review the whole JasperReports integration. That is why I labeled it as Potential-Idea.
Not-002: [IDEMPIERE]
tbayen: nmicoud, about IDEMPIERE-412: which panels do you mean?
nmicoud: panel like GridSequence, FieldSequence
nmicoud: where you can define if an item can be shown or hidden
tbayen: Why not use a Layout that gives all the space of the tab to the panels?
nmicoud: that would be a better solution . The proposed one last of the time i was discovering ui, it should be improved
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-412
Not-002: [IDEMPIERE] Another idea is to give the whole space of the tab to the panel (or both panels). This idea should be reviewed.
Not-002: [IDEMPIERE]
tbayen: I keep this idea in the issue tracker.
nmicoud: sure
tbayen: At the beginning of SMT we connected all issues to IDEMPIERE-588. We had to connect it all manually. I wonder if we can create a filter that does this work in a better way.
tbayen: Like that:
nmicoud: yes, seems a better way.
tbayen: If we solve one in a week we got it together in half a year... :-)
tbayen: Haha
nmicoud: :D
tbayen: There are some "peer review Queue" entries I never mentioned. I will integrate them in the next days/weeks and try them out. We should begin with these to get them into trunk.
nmicoud: ok
tbayen: What about IDEMPIERE-90? I did not use it for a while but I was sure it works. Doesn't it?
nmicoud: it's ok for swing and zk
nmicoud: there is just an enhacement that can be done : for zk, addding an image at the right of the field to show if the list is restricted or not.
nmicoud: actually, you have to do a right click
tbayen: So it is no more a Swing issue. :-)
nmicoud: nope :)
nmicoud: or perhaps the 90 can be closed and a new one can be opened for the enhancement ?
tbayen: The description and comments do not say clear what the problem is. Either you comment on that or you open a new one.
tbayen: The question is: Is someone interested in doing this? You? If not, the new issue is a case of "Potential-Idea" and close directly..
nmicoud: AFAIR, the component can't allow adding image and it need to be updated or change (see for more detail)
tbayen: AFAIU this is just a "cosmetic" problem of a functionality that is seldom used, right?
tbayen: I would propose to document the remaining parts and link to the meeting explanation and close this one.
nmicoud: ok ; buit that's not only cosmetic. with an image, users can easily see that an action is possible
tbayen: Yes, but this function is nowhere used in the standard installation. If someone uses it he explicit choosed so. Then we can expect that he know what he choosed. - I know that I am not totally true but if we keep the issue open the same will happen: Nothing.
tbayen: Or you research if it is somehow else possible to mark this field. PErhaps you can change the border or the background color or such?!?
nmicoud: actually in zk, there is < and > which surround the label
nmicoud: that's enough if you have good eyes. for 'standard' users it won't be enough. But this can be tracked in a new ticket, as the improvement is only for zk (and the functionnality is implemented and operationnal)
tbayen: yep
Not-002: [IDEMPIERE] nmicoud created IDEMPIERE-1639 Improve ShortList usability
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] nmicoud updated IDEMPIERE-90 status set to "Closed" -resolution set to "Fixed"
Not-002: [IDEMPIERE] Closing the ticket as the feature is implemented. For the usability, a new ticket has been created (1639)
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-588
Not-002: [IDEMPIERE] This issue is not really much used as a "flag" for swing issues. It seems it is too difficult to keep it up to date manually. I recommend using an automatic filter that uses the given JIRA fields. You can use my filter for that:
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-588 status set to "Closed" -assignee set to "Thomas Bayen" -resolution set to "Fixed"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-614 labels set to "Potential-Idea SwingUI webui"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-614 status set to "Closed" -resolution set to "Won't Fix"
Not-002: [IDEMPIERE] Over-aged issue. Set as a Potential-Idea.
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-733
Not-002: [IDEMPIERE] Why not using an ordinary search field entry for this and implement for all(!) search fields the possibility to set a "default value". This has to be configured in the field tab so you can have different defaults for different windows. My next thought is "from-to" defaults.
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hieplq updated IDEMPIERE-1524 Attachment set to "None"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hieplq updated IDEMPIERE-1524 Attachment set to "IDEMPIERE-1524.patch"
Not-002: [IDEMPIERE] I make new pack. please help me review code to I can make pending code more good in new pack i do: + replace old "Generate Charges" by use infoWindow. because search column is easy config + show dialog for link of new charge, error for record make unsuccess + uncheck record make charge success. remain record make unsuccess pending work + in old window "Generate Charges", can make new account also make new charge for new account. + show mas
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hieplq updated IDEMPIERE-1524 status set to "Peer Review Queue"
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] hieplq updated IDEMPIERE-1555 Attachment set to "IDEMPIERE-1555-fixLabelEmpty.patch"
Not-002: [IDEMPIERE] fix error part wrong paramete and went parse empty lable, set record-id as label
Not-002: [IDEMPIERE]
Not-002: [IDEMPIERE] tbayen updated IDEMPIERE-518
Not-002: [IDEMPIERE] While doing Bug Triage and Review I found that this issue is still marked as open. From your description and from your code changes I can not see what really the problem is that is to be solved here. It may be this patch is already applied in a similar way (but not marked as such) or that the issue is solved in a totally other way. I can not find any problems with the actual Swing CComboBox. Can you please tell me if this is still an issue
Not-002: [IDEMPIERE]
nmicoud: @CarlosRuiz: AYT ?
CarlosRuiz: hi
nmicoud: Any news about tickets we talked some weeks ago ? Sorry to harass you but you said you will review them and integrate or say "no" ; do you know when you will be able to do it (because my deadline is getting close) :)
nmicoud: and as i will had to implement them in a production environnment, i need to know if i do it with centralized ids or not
CarlosRuiz: yes nmicoud - I think I wasted this meeting to review your tickets
CarlosRuiz: I'm going out now - but I'll try to review it tomorrow - can I ask you to send me an email with the list?
CarlosRuiz: c u later guys
nmicoud: yes, no problem ; i'll sending it - thanks