Thoughts about timing and Koha schedules
Hi All - ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture. Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong) Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities. (Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period). So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date. I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha. With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha. Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Portland, OR - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
Hi Brendan, This sounds very reasonable. But I just want to add that August is probably not that great for releasing a new version. In July and August the community is not on its most active state of the year :) Marcel ________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Brendan Gallagher [info@bywatersolutions.com] Verzonden: vrijdag 21 augustus 2015 10:56 Aan: Koha Devel Onderwerp: [Koha-devel] Thoughts about timing and Koha schedules Hi All - ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture. Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong) Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities. (Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period). So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date. I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha. With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha. Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan -- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Portland, OR - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com<mailto:info@bywatersolutions.com>
Salvete!
This sounds very reasonable. But I just want to add that August is probably not that great for releasing a new version. In July and August the community is not on its most active state of the year :)
I realise that developers are behind the schedule. However, if we're talking about a timeline that's largely the result of fiscal planning, I think this is a question for the wider general listserv. I would also like to add that there are quite a few Libraries on a September / October fiscal year or have serious budgetary landmarks in that date range. August has also been the forced date of the US Conference. Cheers, Brooke
Hie, Very clever analyze. Now that you say it, November and May are usually also full of projects for us at Biblibre. Le 21/08/2015 10:56, Brendan Gallagher a écrit :
Hi All -
ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture.
Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong)
Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities.
(Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period).
So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date.
I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha.
With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha.
Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com
On the other hand, Novembre and May fit quite well with the KohaCon and the hackfest in Marseille :) 2015-08-21 9:56 GMT+01:00 Brendan Gallagher <info@bywatersolutions.com>:
Hi All -
ByWater is on its 7th year, so we have a solid set of data for analyzing, and recently I've noticed a few things. Let me try and paint the picture.
Major Koha releases are every six months and usually the 22nd day of the month, with the target being November and May. (Please correct me if I am wrong)
Library funding cycles in the US run either fiscal year (July to June), Calendar year (January to December), or some odd fiscal year close to the July~June year. Ok that being said from the time management situation with ByWater that introduces a few complexities.
(Let me describe the workflow and maybe you'll see what I am talking about) Most of the time a library will sign a migration contract with us that dictates we must have them "go-live" before a certain fiscal date OR the library isn't really able to "sign" a contract for services until a certain fiscally motivated date (which places us into a similar roll-out). That being said we find that May and November (plus and minus a month) are our busiest times of the year. I've got 3 people on the road for education/training, 3 people heavily in the fields of migrations scripts, and 3 developers that are heavily in the field of meeting development expectations for lots and lots of go-lives (*note - plus additional staff to support an influx in tickets or other support needs during a go-live period).
So if we slide the releases to say February and August - I would be able to dedicate more man power (9+ people from the above paragraph) around the heavy testing/ debugging / bug writing/squashing periods for a release. I know I know - there isn't really a time that Koha doesn't need more testing, but I've noticed that the volunteer effort is usually much greater/demanding the closer we are to major release date.
I am wondering if others are finding the same with their work schedules (other support providers, academic institutions, public institutions, and my favorite volunteers). Are there certain times of the years where your day job is predictably busy that you aren't able to dedicate the resources that you want towards the greatest project in the world Koha.
With the data set that we're sitting on here, we are constantly seeking ways that we can contribute more. Just a thought and was curious if others analyzed a similar aspect with their environment and perhaps maybe we should bring such a discussion into the open or a general IRC meeting. Especially any of us that are support providers we should be always be thinking about how we can do more for Koha.
Thanks and Cheers (another sleepless night thinking about my favorite subject - Koha), Brendan
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO
Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Portland, OR - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure: (circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% *issue.item.biblio.title* %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %] This (*in bold*) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either. Suggestions would be appreciated. (If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in) Thanks, Blou
You can fill a bug report, it's a bug :) 2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ? Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number? 2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hahaha. Yeah, that part I get. :) But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing. In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :) Thanks, Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
The item var used in the template comes from C4::Circ::AddIssue (called from circ/circulation.pl on checking out an item) which return a DBIx::Class resultset of Issue. Koha::Schema::Result::Issue has a item relationship (belongs_to('item')), so the issue.item.barcode displays what we want. But Koha::Schema::Result::Item (returned by issue.item) does not have a biblio relationship, it has a "biblioitemnumber", but biblioitemnumber will return you a Koha::Schema::Result::Biblioitem which has a relationship to biblio!!!! wonderful isn't it? One thing can be weird: Why it does not explode :) Certainly because TT is kind. So, something like issue.item.biblioitemnumber.biblionumber.title should work... C4::Biblio::GetTitleByIssuenumber could also be fun, but you will have to provide unit tests. Don't forget to take a tablet to relieve the headache... 2015-08-27 16:27 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Hahaha. Yeah, that part I get. :)
But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing.
In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :)
Thanks,
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Already took two this morning. Same pills for head and back aches :) I thought I tried the issue.item.biblioitemnumber.biblionumber.title idea, and it didn't work. But maybe I just wrote biblioitems.biblionumber or some other variation. I'll try again. Thanks a LOT for the help. This does lead me to two followup questions: 1) I thoought the Schema file was created automatically. Why is there a biblioitemnumber and no biblionumber, while both are in Item ? 2) You can just refer me a link for this one, I understand this is large: When are the "subs" accessed? accessing issue.item.biblioitemnumber.biblionumber.title could mean 4 different db access, live when displaying the TT. Or is the whole tree loaded as soon as we handle the issue (which would be a huge access potentially useless). Thanks again! Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 08/27/2015 12:01 PM, Jonathan Druart wrote:
The item var used in the template comes from C4::Circ::AddIssue (called from circ/circulation.pl on checking out an item) which return a DBIx::Class resultset of Issue.
Koha::Schema::Result::Issue has a item relationship (belongs_to('item')), so the issue.item.barcode displays what we want. But Koha::Schema::Result::Item (returned by issue.item) does not have a biblio relationship, it has a "biblioitemnumber", but biblioitemnumber will return you a Koha::Schema::Result::Biblioitem which has a relationship to biblio!!!! wonderful isn't it?
One thing can be weird: Why it does not explode :) Certainly because TT is kind.
So, something like issue.item.biblioitemnumber.biblionumber.title should work... C4::Biblio::GetTitleByIssuenumber could also be fun, but you will have to provide unit tests.
Don't forget to take a tablet to relieve the headache...
2015-08-27 16:27 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Hahaha. Yeah, that part I get. :)
But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing.
In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :)
Thanks,
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
2015-08-27 18:50 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Already took two this morning. Same pills for head and back aches :)
I thought I tried the
issue.item.biblioitemnumber.biblionumber.title
idea, and it didn't work. But maybe I just wrote biblioitems.biblionumber or some other variation. I'll try again.
It should work, let me know if it doesn't.
Thanks a LOT for the help. This does lead me to two followup questions:
1) I thoought the Schema file was created automatically. Why is there a biblioitemnumber and no biblionumber, while both are in Item ?
Show create table items should give you an answer :)
2) You can just refer me a link for this one, I understand this is large: When are the "subs" accessed? accessing
issue.item.biblioitemnumber.biblionumber.title
It comes from the DBIx::Class magic, I don't know... You can set the DBIC debug flag and look at the sql queries generated.
could mean 4 different db access, live when displaying the TT. Or is the whole tree loaded as soon as we handle the issue (which would be a huge access potentially useless).
Thanks again!
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 12:01 PM, Jonathan Druart wrote:
The item var used in the template comes from C4::Circ::AddIssue (called from circ/circulation.pl on checking out an item) which return a DBIx::Class resultset of Issue.
Koha::Schema::Result::Issue has a item relationship (belongs_to('item')), so the issue.item.barcode displays what we want. But Koha::Schema::Result::Item (returned by issue.item) does not have a biblio relationship, it has a "biblioitemnumber", but biblioitemnumber will return you a Koha::Schema::Result::Biblioitem which has a relationship to biblio!!!! wonderful isn't it?
One thing can be weird: Why it does not explode :) Certainly because TT is kind.
So, something like issue.item.biblioitemnumber.biblionumber.title should work... C4::Biblio::GetTitleByIssuenumber could also be fun, but you will have to provide unit tests.
Don't forget to take a tablet to relieve the headache...
2015-08-27 16:27 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Hahaha. Yeah, that part I get. :)
But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing.
In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :)
Thanks,
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Using this:
issue.item.biblioitemnumber.biblionumber.title To access the title of the biblio of the given issue, degrades my dignity as a programmer. How would you then access the biblioitemnumber from Item?
This is so retarded I can't belive this is happening. It shoud be like this issue.item.biblio.title or issue.item.biblioitem.biblio.title to maintain sembalance of FRBR. We should definetely manually create the DBIx::Schema definitions instead of this insanity. DBIx::Schema generator is a really useful tool, but it should be only used to get the crude schema done which is manually fine tuned. Eg. fix the silly join-relations itemnumber, biblionumber, biblioitemnumber. Those are easily overridden in the manual modifications section at the bottom of the Koha/Schema/Result/*.pm-files. Fix the problems, don't exaggerate them! Olli-Antti Kivilahti Järjestelmäkeittäjä vaarakirjastot.fi +358 50 449 7763 --Powered by Kubuntu Linux! On 28.08.2015 11:37, Jonathan Druart wrote:
2015-08-27 18:50 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Already took two this morning. Same pills for head and back aches :)
I thought I tried the
issue.item.biblioitemnumber.biblionumber.title
idea, and it didn't work. But maybe I just wrote biblioitems.biblionumber or some other variation. I'll try again. It should work, let me know if it doesn't.
Thanks a LOT for the help. This does lead me to two followup questions:
1) I thoought the Schema file was created automatically. Why is there a biblioitemnumber and no biblionumber, while both are in Item ? Show create table items should give you an answer :)
2) You can just refer me a link for this one, I understand this is large: When are the "subs" accessed? accessing
issue.item.biblioitemnumber.biblionumber.title It comes from the DBIx::Class magic, I don't know... You can set the DBIC debug flag and look at the sql queries generated.
could mean 4 different db access, live when displaying the TT. Or is the whole tree loaded as soon as we handle the issue (which would be a huge access potentially useless).
Thanks again!
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 12:01 PM, Jonathan Druart wrote:
The item var used in the template comes from C4::Circ::AddIssue (called from circ/circulation.pl on checking out an item) which return a DBIx::Class resultset of Issue.
Koha::Schema::Result::Issue has a item relationship (belongs_to('item')), so the issue.item.barcode displays what we want. But Koha::Schema::Result::Item (returned by issue.item) does not have a biblio relationship, it has a "biblioitemnumber", but biblioitemnumber will return you a Koha::Schema::Result::Biblioitem which has a relationship to biblio!!!! wonderful isn't it?
One thing can be weird: Why it does not explode :) Certainly because TT is kind.
So, something like issue.item.biblioitemnumber.biblionumber.title should work... C4::Biblio::GetTitleByIssuenumber could also be fun, but you will have to provide unit tests.
Don't forget to take a tablet to relieve the headache...
2015-08-27 16:27 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Hahaha. Yeah, that part I get. :)
But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing.
In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :)
Thanks,
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Fix the problems, don't exaggerate them!
Can you please make constructive suggestions without resorting to childish insults? Thanks, -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
I did provide a improvement suggestion,
Eg. fix the silly join-relations itemnumber, biblionumber, biblioitemnumber. Those are easily overridden in the manual modifications section at the bottom of the Koha/Schema/Result/*.pm-files.
but here is a link to the DBIx::Class manual reagrding join mapping: https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/Manual/Joini... Here is a code example from Koha/Schema/Result/Serial.pm # Created by DBIx::Class::Schema::Loader v0.07039 @ 2015-08-18 18:03:03 # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:Q42+PuyJqQu7t1AuVaVdig __PACKAGE__->belongs_to( "subscription", "Koha::Schema::Result::Subscription", { "foreign.subscriptionid" => "self.subscriptionid" }, { cascade_copy => 0, cascade_delete => 0 }, ); Olli-Antti Kivilahti Järjestelmäkeittäjä vaarakirjastot.fi +358 50 449 7763 --Powered by Kubuntu Linux! On 08.09.2015 15:18, Owen Leonard wrote:
Fix the problems, don't exaggerate them! Can you please make constructive suggestions without resorting to childish insults?
Thanks,
-- Owen
Olli: While I can't speak for Owen, I think he might have been taking issue with your language. Even if he wasn't, I do. I don't think it's helpful or in the team spirit to say that someone else's idea "degrades my dignity as a programmer" or "Fix the problems, don't exaggerate them". More importantly, I think it's unacceptable to say "This is so retarded I can't believe this is happening". If that were said at a Koha event, I think it would violate the Community Code of Conduct (http://koha-community.org/about/policy/code-of-conduct/). While "retarded" was common in colloquial English, especially American English, in the '90s, it's not really acceptable anymore. Feel free research ableism for explanations why. That all said, I agree with what you're saying technically. While the DBIx::Class::Schema::Loader had a function at the start, I don't think we should be relying on it anymore. Feel free to look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5837 and http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11390 and http://wiki.koha-community.org/wiki/DB_schema_bugs#Koha_DBIx::Class_Problems for more information on moving forward using DBIx::Class for deploying the schema. I'm no longer working on these issues, as I have other more pressing concerns, but I'm in total agreement that we should be managing the database using DBIx::Class rather than the hybrid model we're currently using. Feel free to pick up where I left off, or just make the manual modifications, which you've mentioned, or advocate for the manual modifications without disparaging other developers. I know sometimes I get worked up over what I perceive to be foolishness or insanity. I think we've all lost our composure at one time or another on IRC, or Bugzilla, or the listserv. But I don't think it's helpful to vent that frustration at others. I think what Owen was indicating with his message was that it is helpful to outline why an idea is bad, but it's not helpful to attach additional value judgements to that idea or the people behind it. That has the potential to discourage developers (both new and established), cause tensions within the team which hinders cooperation, and generally isn't a very nice thing to do, which is important since I think Koha is a nice place to be overall. In any case, I don't mean this as an attack. I agree with what you're saying technically, even if I don't agree with the way it was said. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Kivilahti Olli-Antti Sent: Tuesday, 8 September 2015 11:02 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Question about Schema
I did provide a improvement suggestion,
Eg. fix the silly join-relations itemnumber, biblionumber, biblioitemnumber. Those are easily overridden in the manual modifications section at the bottom of the Koha/Schema/Result/*.pm-files.
but here is a link to the DBIx::Class manual reagrding join mapping:
https://metacpan.org/pod/distribution/DBIx- Class/lib/DBIx/Class/Manual/Joining.pod
Here is a code example from Koha/Schema/Result/Serial.pm
# Created by DBIx::Class::Schema::Loader v0.07039 @ 2015-08-18 18:03:03 # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:Q42+PuyJqQu7t1AuVaVdig
__PACKAGE__->belongs_to( "subscription", "Koha::Schema::Result::Subscription", { "foreign.subscriptionid" => "self.subscriptionid" }, { cascade_copy => 0, cascade_delete => 0 }, );
Olli-Antti Kivilahti Järjestelmäkeittäjä vaarakirjastot.fi +358 50 449 7763 --Powered by Kubuntu Linux!
On 08.09.2015 15:18, Owen Leonard wrote:
Fix the problems, don't exaggerate them! Can you please make constructive suggestions without resorting to childish insults?
Thanks,
-- Owen
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha- community.org/ bugs : http://bugs.koha-community.org/
Hi all, Il 09/09/2015 01:45, David Cook ha scritto:
While "retarded" was common in colloquial English, especially American English, in the '90s, it's not really acceptable anymore. Feel free research ableism for explanations why.
we need to rember that we at leat 5 different 'English' inside us: 1)American English 2)UK English 3)India English 4)AUS/NZ English 5)English as second languge in the rest of the world. With a mix of Western/No Western coltures. Bye Zeno Tajoli -- Zeno Tajoli /Dipartimento Sviluppi Innovativi/ - Automazione Biblioteche Email: z.tajoli@cineca.it Fax: 051/6132198 *CINECA* Consorzio Interuniversitario - Sede operativa di Segrate (MI)
On 9 September 2015 8:43:49 pm NZST, Tajoli Zeno <z.tajoli@cineca.it> wrote:
Hi all,
Il 09/09/2015 01:45, David Cook ha scritto:
While "retarded" was common in colloquial English, especially American English, in the '90s, it's not really acceptable anymore. Feel free research ableism for explanations why.
we need to rember that we at leat 5 different 'English' inside us: 1)American English 2)UK English 3)India English 4)AUS/NZ English 5)English as second languge in the rest of the world.
With a mix of Western/No Western coltures.
All that is true, but the main point is retarded is offensive so if people can bear that in mind in future, that would be great. Thanks Chris
Bye Zeno Tajoli
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
See bug 14819 for a patch and also bug 14818 (omnibus). 2015-09-08 9:08 GMT+01:00 Kivilahti Olli-Antti <olli-antti.kivilahti@jns.fi>:
Using this:
issue.item.biblioitemnumber.biblionumber.title To access the title of the biblio of the given issue, degrades my dignity as a programmer. How would you then access the biblioitemnumber from Item?
This is so retarded I can't belive this is happening.
It shoud be like this
issue.item.biblio.title or issue.item.biblioitem.biblio.title to maintain sembalance of FRBR.
We should definetely manually create the DBIx::Schema definitions instead of this insanity. DBIx::Schema generator is a really useful tool, but it should be only used to get the crude schema done which is manually fine tuned. Eg. fix the silly join-relations itemnumber, biblionumber, biblioitemnumber. Those are easily overridden in the manual modifications section at the bottom of the Koha/Schema/Result/*.pm-files.
Fix the problems, don't exaggerate them!
Olli-Antti Kivilahti Järjestelmäkeittäjä vaarakirjastot.fi +358 50 449 7763 --Powered by Kubuntu Linux!
On 28.08.2015 11:37, Jonathan Druart wrote:
2015-08-27 18:50 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Already took two this morning. Same pills for head and back aches :)
I thought I tried the
issue.item.biblioitemnumber.biblionumber.title
idea, and it didn't work. But maybe I just wrote biblioitems.biblionumber or some other variation. I'll try again. It should work, let me know if it doesn't.
Thanks a LOT for the help. This does lead me to two followup questions:
1) I thoought the Schema file was created automatically. Why is there a biblioitemnumber and no biblionumber, while both are in Item ? Show create table items should give you an answer :)
2) You can just refer me a link for this one, I understand this is large: When are the "subs" accessed? accessing
issue.item.biblioitemnumber.biblionumber.title It comes from the DBIx::Class magic, I don't know... You can set the DBIC debug flag and look at the sql queries generated.
could mean 4 different db access, live when displaying the TT. Or is the whole tree loaded as soon as we handle the issue (which would be a huge access potentially useless).
Thanks again!
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 12:01 PM, Jonathan Druart wrote:
The item var used in the template comes from C4::Circ::AddIssue (called from circ/circulation.pl on checking out an item) which return a DBIx::Class resultset of Issue.
Koha::Schema::Result::Issue has a item relationship (belongs_to('item')), so the issue.item.barcode displays what we want. But Koha::Schema::Result::Item (returned by issue.item) does not have a biblio relationship, it has a "biblioitemnumber", but biblioitemnumber will return you a Koha::Schema::Result::Biblioitem which has a relationship to biblio!!!! wonderful isn't it?
One thing can be weird: Why it does not explode :) Certainly because TT is kind.
So, something like issue.item.biblioitemnumber.biblionumber.title should work... C4::Biblio::GetTitleByIssuenumber could also be fun, but you will have to provide unit tests.
Don't forget to take a tablet to relieve the headache...
2015-08-27 16:27 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Hahaha. Yeah, that part I get. :)
But I was somewhat hoping that this forum was also about allowing people to ask technical questions about the code, not just being a closed conversation between knowledgeable people about the next release/next big thing.
In the case of 14726, I would have thought the generated part of the Schema would contain the link item->biblio. But maybe 1) it's something that failed (so the bug is in the Schema generation) 2) it's something that must be coded (but why?) 3) it's too obvious, I'm just clueless... Which is somewhat an unsatisfying answer. :)
Thanks,
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/27/2015 11:16 AM, Jonathan Druart wrote:
You know what's next, I won't explain you ;) (do, pay or wait) What's the bug number?
2015-08-27 15:15 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
A bug has been filled. What next? Isn't it a good forum to ask "what happened"/"what's missing" ?
Philippe Blouin, Responsable du développement informatique
Tél. : (888) 604-2627 philippe.blouin@inLibro.com
inLibro | pour esprit libre | www.inLibro.com On 08/25/2015 10:27 AM, Jonathan Druart wrote:
You can fill a bug report, it's a bug :)
2015-08-25 14:57 GMT+01:00 Philippe Blouin <philippe.blouin@inlibro.com>:
Simple question I'm sure, but there's this bug in circulation.tt that shows I haven't played much with the new Schema structure:
(circulation.tt, line 672) [% IF ( issue ) %] <div class="lastchecked"> <p><strong>Checked out: </strong>[% issue.item.biblio.title %] ([% issue.item.barcode %]). Due on [% issue.date_due | $KohaDates %]</p> </div> [% END %]
This (in bold) never shows up. The item.biblio link, well, it doesn't exists in the Result::Item per my understanding. Whatever I tried with biblioitem(s) in between didn't pan either.
Suggestions would be appreciated.
(If this is indeed a bug and not a code 18, I'll be happy to do the "paperwork" to file it in)
Thanks, Blou
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (11)
-
Brendan Gallagher -
BWS Johnson -
Chris Cormack -
David Cook -
Fridolin SOMERS -
Jonathan Druart -
Kivilahti Olli-Antti -
Marcel de Rooy -
Owen Leonard -
Philippe Blouin -
Tajoli Zeno