GST and discount not calculating correctly when placing an order in 3.0 acquisitions.
/(last one from me for the day I promise ..)/ Greetings all, I have just placed an order for a book in my new Koha 3.0 test site. The supplier profile is set with list/ordering price and invoice price both inclusive of GST (12.5%) The supplier gives a 15% discount. I ordered a book with a List price of $75. (See attachment for the screen shots showing the input screen and the order details screen.) The amount to be deducted from the budget needs to be exclusive of GST and discount ie the actual net cost to us of purchasing the item. So RRP $75 less GST (divided by 1.125) = a GST exclusive price of $66.66. Then if we deduct the 15% ($9.99) off the ex-GST price the book is actually $56.67. What appears to be happening is that Koha 3.0 then adds GST of 12.5% ($7.08) back on to the $56.67 to arrive at the $63.75 which is then deducted off the budget. This is the wrong amount. I think this may be a bug. Where does one log such things? And how do we incorporate a patch back into my demo site? Cheers Jo. (PS We have used Koha acquisitions for 8 years and are very familiar with the intricacies of it - by way of explanation for appearing so pedantic and obsessed about it!)
On Sun, Dec 14, 2008 at 11:04 PM, Joann Ransom <jransom@library.org.nz> wrote:
/(last one from me for the day I promise ..)/
Greetings all,
I have just placed an order for a book in my new Koha 3.0 test site.
The supplier profile is set with list/ordering price and invoice price both inclusive of GST (12.5%) The supplier gives a 15% discount.
I ordered a book with a List price of $75. (See attachment for the screen shots showing the input screen and the order details screen.)
The amount to be deducted from the budget needs to be exclusive of GST and discount ie the actual net cost to us of purchasing the item.
So RRP $75 less GST (divided by 1.125) = a GST exclusive price of $66.66. Then if we deduct the 15% ($9.99) off the ex-GST price the book is actually $56.67.
What appears to be happening is that Koha 3.0 then adds GST of 12.5% ($7.08) back on to the $56.67 to arrive at the $63.75 which is then deducted off the budget. This is the wrong amount.
I think this may be a bug. Where does one log such things? And how do we incorporate a patch back into my demo site? You can log bugs at http://bugs.koha.org.
(PS We have used Koha acquisitions for 8 years and are very familiar with the intricacies of it - by way of explanation for appearing so pedantic and obsessed about it!) Yes, however, the version of Koha you're running doesn't match released versions (whether by code or by templates). I think it's great that you're looking to run off of a released version, and I hope you're able to contribute the necessary bugfixes and patches so that upcoming releases will incorporate all of the functionality you're using -- I'm sure there are a lot of libraries in NZ and elsewhere that use GST exactly the way you do.
Perhaps BibLibre can comment on whether the GST calculation described above by Joann is the same GST calculation done in France? We don't have GST in the US, so I can't comment on how it's calculated here. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi Joshua, You may or may not recall that Horowhenua Library Trust funded the development of Koha 1.0 and released it as Open Source. We have contributed hundreds of thousands of dollars to the project already, and have a dam fine acquisitions system which we have used for 8 years, but which someone chose to rewrite or remove from the official release. regards Jo. Joshua Ferraro wrote:
On Sun, Dec 14, 2008 at 11:04 PM, Joann Ransom <jransom@library.org.nz> wrote:
/(last one from me for the day I promise ..)/
Greetings all,
I have just placed an order for a book in my new Koha 3.0 test site.
The supplier profile is set with list/ordering price and invoice price both inclusive of GST (12.5%) The supplier gives a 15% discount.
I ordered a book with a List price of $75. (See attachment for the screen shots showing the input screen and the order details screen.)
The amount to be deducted from the budget needs to be exclusive of GST and discount ie the actual net cost to us of purchasing the item.
So RRP $75 less GST (divided by 1.125) = a GST exclusive price of $66.66. Then if we deduct the 15% ($9.99) off the ex-GST price the book is actually $56.67.
What appears to be happening is that Koha 3.0 then adds GST of 12.5% ($7.08) back on to the $56.67 to arrive at the $63.75 which is then deducted off the budget. This is the wrong amount.
I think this may be a bug. Where does one log such things? And how do we incorporate a patch back into my demo site?
You can log bugs at http://bugs.koha.org.
(PS We have used Koha acquisitions for 8 years and are very familiar with the intricacies of it - by way of explanation for appearing so pedantic and obsessed about it!)
Yes, however, the version of Koha you're running doesn't match released versions (whether by code or by templates). I think it's great that you're looking to run off of a released version, and I hope you're able to contribute the necessary bugfixes and patches so that upcoming releases will incorporate all of the functionality you're using -- I'm sure there are a lot of libraries in NZ and elsewhere that use GST exactly the way you do.
Perhaps BibLibre can comment on whether the GST calculation described above by Joann is the same GST calculation done in France? We don't have GST in the US, so I can't comment on how it's calculated here.
Cheers,
Hi Joann, I can see you've taken offense at my comments, which was not my intention. What I meant to explain is that while you certainly may have an excellent acquisitions system that's been in use for over 8 years at HLT, we've never seen it ... it's never worked properly as contributed to the community. Whether this is as a result of custom templates, or custom code that was never contributed, i can't say as I don't have a way to review your installation ... I don't think it's a matter of someone rewriting or removing your acquisitions system from the release ... it was never in there to begin with. Cheers, Josh On Tue, Dec 16, 2008 at 3:59 PM, Joann Ransom <jransom@library.org.nz> wrote:
Hi Joshua,
You may or may not recall that Horowhenua Library Trust funded the development of Koha 1.0 and released it as Open Source. We have contributed hundreds of thousands of dollars to the project already, and have a dam fine acquisitions system which we have used for 8 years, but which someone chose to rewrite or remove from the official release.
regards
Jo.
Joshua Ferraro wrote:
On Sun, Dec 14, 2008 at 11:04 PM, Joann Ransom <jransom@library.org.nz> wrote:
/(last one from me for the day I promise ..)/
Greetings all,
I have just placed an order for a book in my new Koha 3.0 test site.
The supplier profile is set with list/ordering price and invoice price both inclusive of GST (12.5%) The supplier gives a 15% discount.
I ordered a book with a List price of $75. (See attachment for the screen shots showing the input screen and the order details screen.)
The amount to be deducted from the budget needs to be exclusive of GST and discount ie the actual net cost to us of purchasing the item.
So RRP $75 less GST (divided by 1.125) = a GST exclusive price of $66.66. Then if we deduct the 15% ($9.99) off the ex-GST price the book is actually $56.67.
What appears to be happening is that Koha 3.0 then adds GST of 12.5% ($7.08) back on to the $56.67 to arrive at the $63.75 which is then deducted off the budget. This is the wrong amount.
I think this may be a bug. Where does one log such things? And how do we incorporate a patch back into my demo site?
You can log bugs at http://bugs.koha.org.
(PS We have used Koha acquisitions for 8 years and are very familiar with the intricacies of it - by way of explanation for appearing so pedantic and obsessed about it!)
Yes, however, the version of Koha you're running doesn't match released versions (whether by code or by templates). I think it's great that you're looking to run off of a released version, and I hope you're able to contribute the necessary bugfixes and patches so that upcoming releases will incorporate all of the functionality you're using -- I'm sure there are a lot of libraries in NZ and elsewhere that use GST exactly the way you do.
Perhaps BibLibre can comment on whether the GST calculation described above by Joann is the same GST calculation done in France? We don't have GST in the US, so I can't comment on how it's calculated here.
Cheers,
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Wed, Dec 17, 2008 at 10:34 AM, Joshua Ferraro <jmf@liblime.com> wrote:
Hi Joann,
I can see you've taken offense at my comments, which was not my intention. What I meant to explain is that while you certainly may have an excellent acquisitions system that's been in use for over 8 years at HLT, we've never seen it ... it's never worked properly as contributed to the community. Whether this is as a result of custom templates, or custom code that was never contributed, i can't say as I don't have a way to review your installation ...
I don't think it's a matter of someone rewriting or removing your acquisitions system from the release ... it was never in there to begin with.
Heh now you are running the risk of offending me. Everything, every single thing that was in koha 1.0 was released , including the acquisitions system. The whole thing was one big tarball, there was nothing that was in 1.0 that wasnt released. Things may have slipped out, or not been updated when things were changed in the multitude of releases and commits since then. But there was nothing that hlt had (remember templates werent even used in 1.0 it was perl and html files) for 1.0 that wasn't committed. Chris
On Wed, Dec 17, 2008 at 10:34 AM, Joshua Ferraro <jmf@liblime.com> wrote:
Hi Joann,
I can see you've taken offense at my comments, which was not my intention. What I meant to explain is that while you certainly may have an excellent acquisitions system that's been in use for over 8 years at HLT, we've never seen it ... it's never worked properly as contributed to the community. Whether this is as a result of custom templates, or custom code that was never contributed, i can't say as I don't have a way to review your installation ...
I don't think it's a matter of someone rewriting or removing your acquisitions system from the release ... it was never in there to begin with.
Heh now you are running the risk of offending me. Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working
Everything, every single thing that was in koha 1.0 was released , including the acquisitions system. The whole thing was one big tarball, there was nothing that was in 1.0 that wasnt released.
Things may have slipped out, or not been updated when things were changed in the multitude of releases and commits since then. But there was nothing that hlt had (remember templates werent even used in 1.0 it was perl and html files) for 1.0 that wasn't committed. I wasn't around for 1.0, so I can't comment on whether HLT's code was
On Tue, Dec 16, 2008 at 4:40 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote: form to the Koha project. perfectly in sync with 1.0. But come to think of it, I tend to believe you. I've even seen code in Koha that contained HLT-specific strings, so I don't doubt that at one point 9 years ago when Koha was first released, HLT was running on THE release ... 1.0. Inspecting the Git repo a bit even turns up some HLT-specific stuff still hanging around: C4/Print.pm line 101: print PRINTER "Horowhenua Library Trust\r\n"; C4/Circulation.pm line 801: if ( C4::Context->preference("LibraryName") eq "Horowhenua Library Trust" ) { Presumably, Context works a bit differently if your LibraryName is set to the string "Horowhenua Library Trust". However, I don't think you're arguing that 1.0 acquisitions was working, at least I hope you're not. HLT's current Acquisitions has a ton more functionality than it did 9 years ago, right? How about bug fixes? Where are those additional functions and bug fixes? All I'm saying is that since 1.0, when presumably HLT and the 1.0 release were in sync, there's never been a release of Koha that incorporated a working HLT-style acquisitions system. Last I checked, HLT runs on a modified Version 2.2 Koha. In order to do that upgrade, HLT had to port their local changes forward into 2.2 ... but, those changes weren't ported forward and contributed in a working form to the community. Like I said, without further investigation, I can't comment on whether it's code or templates that are locally modified on HLT's system and remain un-contributed, but there are clearly differences between Koha 2.2 Acquisitions, and HLT 2.2 Acquisitions. Hope that explains what I'm saying ... and again, my intention here is not to offend anyone. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way. Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services It isn't pollution that's harming the environment. It's the impurities in our air and water that are doing it. -- Al Gore, Vice President
On Tue, Dec 16, 2008 at 10:00 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way.
Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. All the publicly released versions of Koha that I know about are up at:
http://download.koha.org/ So if someone wants to install an earlier version, they're all there. Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Wed, Dec 17, 2008 at 11:17 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Tue, Dec 16, 2008 at 10:00 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way.
Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. All the publicly released versions of Koha that I know about are up at:
So if someone wants to install an earlier version, they're all there.
That's not all of them, that was all the ones I had on my old HD, there are 1.00 and 1.01 as well and a few more 1.2.x. It's also missing a few 1.9.x releases too. If someone really doesn't believe that the first release of Koha was me tarring up the version that was in production in HLT and putting it up on the web for people to download. Then so be it. Anyway its time for this thread to die, suffice to say HLT had acquisitions they liked in 2000, 3.0 doesnt have those same abilities (of course its better in many many other ways). So they would like them back. Which will mean that sooner or later they will get added back. Lets call it a day and move on eh? Chris
On Wed, Dec 17, 2008 at 5:27 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On Wed, Dec 17, 2008 at 11:17 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Tue, Dec 16, 2008 at 10:00 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way.
Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. All the publicly released versions of Koha that I know about are up at:
So if someone wants to install an earlier version, they're all there.
That's not all of them, that was all the ones I had on my old HD, there are 1.00 and 1.01 as well and a few more 1.2.x. It's also missing a few 1.9.x releases too. If someone really doesn't believe that the first release of Koha was me tarring up the version that was in production in HLT and putting it up on the web for people to download. Then so be it.
Anyway its time for this thread to die, suffice to say HLT had acquisitions they liked in 2000, 3.0 doesnt have those same abilities (of course its better in many many other ways). So they would like them back. Which will mean that sooner or later they will get added back.
Lets call it a day and move on eh? If we avoid confrontation and airing these issues publicly, how will we avoid them moving forward?
I'd hate to see the same cycle repeating every few versions as it has done for the past 9 years, where HLT and similar customers run local versions of code, thinking that they're running publicly available versions and that others have broken the stuff they contributed, and then complaining about it and pointing the finger at the last RM (which in this case happens to be me). A better model is to contribute stuff in such a way that everyone can use it, not to silo stuff behind custom templates so that it only works if you're running non-contributed templates, and to constantly keep in sync with the community's latest version releases. Anyway, I've said it better in the other acq thread. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On Wed, Dec 17, 2008 at 11:54 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Wed, Dec 17, 2008 at 5:27 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On Wed, Dec 17, 2008 at 11:17 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Tue, Dec 16, 2008 at 10:00 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way.
Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. All the publicly released versions of Koha that I know about are up at:
So if someone wants to install an earlier version, they're all there.
That's not all of them, that was all the ones I had on my old HD, there are 1.00 and 1.01 as well and a few more 1.2.x. It's also missing a few 1.9.x releases too. If someone really doesn't believe that the first release of Koha was me tarring up the version that was in production in HLT and putting it up on the web for people to download. Then so be it.
Anyway its time for this thread to die, suffice to say HLT had acquisitions they liked in 2000, 3.0 doesnt have those same abilities (of course its better in many many other ways). So they would like them back. Which will mean that sooner or later they will get added back.
Lets call it a day and move on eh? If we avoid confrontation and airing these issues publicly, how will we avoid them moving forward?
I'd hate to see the same cycle repeating every few versions as it has done for the past 9 years, where HLT and similar customers run local versions of code, thinking that they're running publicly available versions and that others have broken the stuff they contributed, and then complaining about it and pointing the finger at the last RM (which in this case happens to be me).
A better model is to contribute stuff in such a way that everyone can use it, not to silo stuff behind custom templates so that it only works if you're running non-contributed templates, and to constantly keep in sync with the community's latest version releases. Anyway, I've said it better in the other acq thread.
Ok since this thread won't die. HLT ran koha 1.0 ... which had acquisitions working in a way they liked. There were no custom templates,. there were no templates period. There was no web based circulation, there was CDK based circulation. Their next upgrade was to 1.2.4. This had the web based circulation, the beginnings of MARC import, and acquisitions that still worked towards in a way they want. They held off upgrading to 2.0 and their next upgrade was to 2.2.9, which no longer had working acquisitions. In June of 2006 we endeavoured to commit all the fixes we made to make acquisitions work again for them. Notably these commits here http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=2ee33... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=ad249... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=48b5c... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=16954... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=4e8e4... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=0dd1e... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=91a1e... Then in July http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=567c7... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=b9b3e... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=3aad0... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=c2822... At that point all the changes we had made for 2.2.9 to work the way it is now for them still, should have been committed. I have never pointed the finger at you Joshua, nor have I said that the reason acquisitions arent working the way HLT expect in 3.0 is due to your work as RM. Id appreciate if you would step back and stop HLT (the reason Koha exists) feel like they have done something wrong. Chris
On Wed, Dec 17, 2008 at 6:43 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On Wed, Dec 17, 2008 at 11:54 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Wed, Dec 17, 2008 at 5:27 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On Wed, Dec 17, 2008 at 11:17 PM, Joshua Ferraro <jmf@liblime.com> wrote:
On Tue, Dec 16, 2008 at 10:00 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way.
Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. All the publicly released versions of Koha that I know about are up at:
So if someone wants to install an earlier version, they're all there.
That's not all of them, that was all the ones I had on my old HD, there are 1.00 and 1.01 as well and a few more 1.2.x. It's also missing a few 1.9.x releases too. If someone really doesn't believe that the first release of Koha was me tarring up the version that was in production in HLT and putting it up on the web for people to download. Then so be it.
Anyway its time for this thread to die, suffice to say HLT had acquisitions they liked in 2000, 3.0 doesnt have those same abilities (of course its better in many many other ways). So they would like them back. Which will mean that sooner or later they will get added back.
Lets call it a day and move on eh? If we avoid confrontation and airing these issues publicly, how will we avoid them moving forward?
I'd hate to see the same cycle repeating every few versions as it has done for the past 9 years, where HLT and similar customers run local versions of code, thinking that they're running publicly available versions and that others have broken the stuff they contributed, and then complaining about it and pointing the finger at the last RM (which in this case happens to be me).
A better model is to contribute stuff in such a way that everyone can use it, not to silo stuff behind custom templates so that it only works if you're running non-contributed templates, and to constantly keep in sync with the community's latest version releases. Anyway, I've said it better in the other acq thread.
Ok since this thread won't die. HLT ran koha 1.0 ... which had acquisitions working in a way they liked. There were no custom templates,. there were no templates period. There was no web based circulation, there was CDK based circulation. Their next upgrade was to 1.2.4. This had the web based circulation, the beginnings of MARC import, and acquisitions that still worked towards in a way they want. They held off upgrading to 2.0 and their next upgrade was to 2.2.9, which no longer had working acquisitions.
In June of 2006 we endeavoured to commit all the fixes we made to make acquisitions work again for them. Notably these commits here
http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=2ee33... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=ad249... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=48b5c... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=16954... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=4e8e4... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=0dd1e... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=91a1e...
Then in July http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=567c7... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=b9b3e... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=3aad0... http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=commitdiff;h=c2822...
At that point all the changes we had made for 2.2.9 to work the way it is now for them still, should have been committed. OK, easy enough to say that, but the fact is, if you look more closely, you'll see that in fact, it's not the case that Acquisitions was working at this point in 2.2.9 without either custom code on HLT's server, or custom templates that weren't in fact committed.
This is easily proven, just do a recursive diff on HLT's server against the 2.2.9 snapshot, or if you like, against any point in time you like of the git history you've pasted above. The indirect proof that the community has is that HLT says their Acquisitions works, whereas I know that 2.2.9 acquisitions doesn't work and never has. Is anyone seriously questioning the broken state of Acquisitions in 2.2.9?
I have never pointed the finger at you Joshua, nor have I said that the reason acquisitions arent working the way HLT expect in 3.0 is due to your work as RM. And I didn't say you did specifically, but there are hits being dropped all the time about 'this is how it used to work' and 'someone has changed it'. The fact is, it DID NOT work that way, and we DID NOT change it, we tried to fix it.
Id appreciate if you would step back and stop HLT (the reason Koha exists) feel like they have done something wrong. Again, that's not my intention. I'm not trying to hurt anyone's feelings, I'm trying to air an issue that I hope we can avoid in the future. I'm sure HLT are confused as to why the community perceives that their Acquisition system doesn't work as advertised, and why 2.2.9 and 3.0 don't have features that they 'contributed'. The reason is that they WERE NOT EVER FULLY CONTRIBUTED in a way that the rest of the community could use them, and we've never seen them in a working state.
My goal here is not to point fingers, lay blame, or piss people off. I'd honestly like to make sure we all agree and understand the complexity of community participation, avoid the pitfalls of localized, un-contributed code and templates, and move forward in a way that everyone in the community can collaborate on features and functionality in a productive way, that doesn't require hopscotch between versions, which as I've said in another thread is both frustrating and expensive for the users. We have to all take a step back here and be honest about why things are the way they are. There are tensions between the segments of this community and digging our heads in the sand isn't going to help us resolve them and move forward as a community. I for one would like to see future versions of Koha work 'out of the box' for HLT, NPL, San-OP and all of the other major contributors to the codebase, so that they could upgrade seamlessly (quarterly perhaps) without any fear of losing or changing functionality. But we'll never get there unless the features that HLT uses are contributed to the community in full, as completely-functional features, both code and templates, and any bugfixes applied post-release are also applied to the community, not just to HLT. Joann, I'm sorry HLT has to be the 'example' here, there are plenty of other Koha libraries that have fallen into the same trap, and I sincerely hope we can all work together to make sure that the needs of everyone in this community are met by future releases. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Ok point made, things havent always been committed fully. BUT also things do get broken when other features are added. THIS HAS ALSO HAPPENED, lets not bury our head in the sands over that fact either. This will be my last post on this issue, because I'm starting to talk in caps :) Chris
[ERM... the following message originally had FOUR recipients and was sent to the moderators. why? what is so evil about three recipients on top of the list itself?] Joshua Ferraro wrote:
Offense is not my goal, I'm just being honest and pointing out the facts: HLT's localized Koha installations, presumably post 1.0 release, contain functionality that wasn't contributed in a working form to the Koha project.
Why not solve this the easy way. Make the Koha 1.0 tarball available. Someone on the list will volunteer to install it on a fresh machine. We can then look at the acquisitions system therein and see if it meets requirements. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services It isn't pollution that's harming the environment. It's the impurities in our air and water that are doing it. -- Al Gore, Vice President
On Wed, Dec 17, 2008 at 4:16 PM, Rick Welykochy <rick@praxis.com.au> wrote:
[ERM... the following message originally had FOUR recipients and was sent to the moderators. why? what is so evil about three recipients on top of the list itself?]
Spammers send mail to lots of addresses at once, its just a simple spam check. Don't worry about it. Chris
Chris Cormack wrote:
Spammers send mail to lots of addresses at once, its just a simple spam check. Don't worry about it.
I'm not worried in the slightest. I am astonished. cheers rickw "member of many mailing lists" -- _________________________________ Rick Welykochy || Praxis Services It isn't pollution that's harming the environment. It's the impurities in our air and water that are doing it. -- Al Gore, Vice President
On Wed, Dec 17, 2008 at 4:38 PM, Rick Welykochy <rick@praxis.com.au> wrote:
Chris Cormack wrote:
Spammers send mail to lots of addresses at once, its just a simple spam check. Don't worry about it.
I'm not worried in the slightest. I am astonished.
That's nice. /me goes back to doing work Chris
participants (4)
-
Chris Cormack -
Joann Ransom -
Joshua Ferraro -
Rick Welykochy