---- Reported by jmf@liblime.com 2007-09-29 06:39:16 ---- ---- Additional Comments From paul.poulain@biblibre.com 2007-10-05 08:49:42 ---- I don't understand what you mean here. In the biblio view, the "subscription" link is available only if you have already a subscription, so no need to add it. In serials-home.pl, you can search for more than 1 biblio, so we can't fill automatically the biblionumber. I reassign the bug to you, you'll specify what you want, or you will do it yourself ;-) ---- Additional Comments From jmf@liblime.com 2007-10-05 23:59:36 ---- Using our new template design, the 'subscription' page is really just a 'view' of the bibliographic record. The subscription page currently lists all of the subscriptions attached to a biblio. If you click on the 'add subscription' link from a specific biblio (no matter what 'view'), it should pre-populate the biblionumber for that subscription to be the same as the biblio you started from. In this way, it would be trivial to add new subscriptions to a given biblio in the case where more than one subscription is needed. Does that clarify? All we need is a new param for 'biblionumber' that can be added ?biblionumber=N that pre-populates the bib number in the subscription planning page. ---- Additional Comments From paul.poulain@biblibre.com 2007-10-26 08:06:33 ---- but : the subscription page can show more than one subscription if you enter a partial title in the filter (you're speaking of serials-home.pl, when you have entered a title or issn right ?) In this case, the "new subscription" can't automatically retrieve the biblionumber, as there may be more than one. Or there is still something i haven't understood... (reassigning to you) ---- Additional Comments From jmf@liblime.com 2008-03-17 20:51:17 ---- When a biblio has at least one subscription, there's a new link added to the detail page on the staff client, called 'Subscriptions'. Why would that use a title-filter when it could use the biblionumber? seems like a very poor design to me. Rather than do a search, there should be an identifier passed to pull up a list of all subscriptions attached to that bibliographic record. There should only be one biblionumber in that case, and the button for 'new subscription' should pre-populate the biblionumber in the resulting new subscription. Does that make more sense? Re-assigning to Paul ---- Additional Comments From jmf@liblime.com 2008-07-20 08:26:11 ---- Assigning to Ryan as he's working on some serials issues, and upping the priority so it grabs our attention during this period of working on Serials in case it's easy to fix. If we don't get to it in 3.0, change the version to rel_3_2. ---- Additional Comments From nengard@gmail.com 2008-08-05 06:42:53 ---- Can someone give a screenshot to explain what this bug is? ---- Additional Comments From henridamien@koha-fr.org 2008-08-05 09:46:35 ---- Created an attachment fixing that "bug" rather an enhancement. ---- Additional Comments From jmf@liblime.com 2008-08-05 10:57:36 ---- This has not been fixed, steps to reproduce: 1. find a record that has a subscription already 2. go to the subscription page, for instance: /cgi-bin/koha/serials/subscription-detail.pl?subscriptionid=1 OR: /cgi-bin/koha/serials/serials-home.pl?searched=1&title_filter=Stand%20tall,%20Molly%20Lou%20Melon%20/ (note that it's a title filter rather than an ID filter which is wrong) 3. Click on 'New Subscription' to add a new subscription to that Title 4. the new subscription page loads with no biblionumber, so you have to start over and search for that title. ---- Additional Comments From jmf@liblime.com 2008-08-06 08:32:02 ---- fixed, thanks Galen! --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 00:30 UTC --- This bug was previously known as _bug_ 1433 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=1433 Imported an attachment (id=339) Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was jmf@liblime.com. The original assignee of this bug does not have an account here. Reassigning to the default assignee for the component, gmcharlt@gmail.com. Previous assignee was rch@liblime.com. The original submitter of attachment 339 [details] [review] is unknown. Reassigning to the person who moved it here: chris@bigballofwax.co.nz.