Summary: | Language inconsistencies on basket groups; skip confirmation when closing basket. | ||
---|---|---|---|
Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
Component: | Acquisitions | Assignee: | Marcel de Rooy <m.de.rooy> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | minor | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, colin.campbell, koha.sekjal, m.de.rooy, paul.poulain |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: |
Patch
Screen shot Rebased patch Follow up patch for install Follow up patch for installing pref Installation patch for 3.4.X |
Description
Nicole C. Engard
2010-07-07 21:05:54 UTC
I think there is a need for a vocabulary list defining the concepts used in acquisitions. Baskets seems especially problematic as its a terminology not used by any acquisitions librarians I'm encountering and after explaining it some then say 'But why would we want that? can you hide the baskets?'. And its important to know what it means as the language is very loose in practse (how many definitions of order does your library use?) Compared to other systems I'm aware of our basket == order our order == orderline. But in modern systems orders much more often have a 1 orderline per order style. (I'm just glad I don't have to translate this) I'm with you on that - but I was concerned about suggesting a change from basket since it has been that way so long and librarians using Koha have gotten used to it. I am training today and I did have to explain that a basket is an order and that a basket group is a purchase order - as for and order == orderline - where does Koha Acq refer to orders? As of today, the master version still asks if I want to create an purchase order. This is really confusing. It is not evident AT ALL that this means that a basket group is created. In my interpretation, a purchase order in Koha is still not more than an order line. If I really do not want basket groups, I would even prefer an option to get rid of this question and the possible creation of these groups when somebody unadvertently clicks the checkbox. Sending a proposed patch to dev list. Comments are welcome. This patch adds a new pref SkipBasketConfirmations. This adds the option to skip confirmations on closing and reopening a basket. If you skip the confirm, you do not create a new basket group. The confusing line Create a purchase order (when closing a basket) is replaced by Attach basket to a new basket group with the same name. A warning for a null value on basketgroupid is fixed. See http://lists.koha-community.org/pipermail/koha-patches/2010-November/013102.html Revised patch. See http://lists.koha-community.org/pipermail/koha-patches/2010-November/013115.html Preference renamed to BasketConfirmations in order to prevent double negative (not skip...) Created attachment 2999 [details] [review] Patch The patch applies, does what he said, but i've some troubles with what it does: if you don't create "basketgroups" (whatever you call them ;-) ), it means you can't create PDFs. Is it what you want to do ? I was thinking that with this syspref being set, you had'nt the question, but the basketgroup was automatically created, without asking, to have librarians getting the PDF immediatly. That would be handy for libraries that create one basket, close it and it's done. (In reply to comment #7) > The patch applies, does what he said, but i've some troubles with what it does: > if you don't create "basketgroups" (whatever you call them ;-) ), it means you > can't create PDFs. Is it what you want to do ? > I was thinking that with this syspref being set, you had'nt the question, but > the basketgroup was automatically created, without asking, to have librarians > getting the PDF immediatly. > That would be handy for libraries that create one basket, close it and it's > done. That's why I created it. We use it that way. Actually, we print or mail a custom pdf file from the basket screen already. By default, the confirmation question appears however. So it should not be a problem for anybody? Hi Marcel, Paul and I were discussing the workflow you describe. Do you use the PDF creation feature from basket groups or do you create the PDF in another way? Like using a plugin for Firefox? Created attachment 3735 [details] Screen shot In reply to comment9: We have a custom Print/Mail button on basket.pl Created attachment 3862 [details] [review] Rebased patch Rebased for TT. This is the first patch to be rebased onto Template::Toolkit, a big thank you to Marcel and please can we get this signed off as a reward :) Sign off from Colin on the mailing list: http://lists.koha-community.org/pipermail/koha-patches/2011-April/014801.html The database and sql files are missing from the patch! Created attachment 4009 [details] [review] Follow up patch for install Rebased patch still applies to master (3.05.00.001). Has been signed already. Second follow up patch installs the pref. Needs still signoff. Created attachment 4010 [details] [review] Follow up patch for installing pref Follow up patch signed off and sent to the list QA comment Reading the patch and thinking of ergonomy rules we try to follow in Koha, I think this patch addresses a problem, but in a wrong way. Ergonomic rule = don't ask for confirmation if you can cancel the operation. For example, when you add something, you can delete it after, so don't ask "do you want to add this". Usually, confirmations are added only for deletions. So I would say : * remove the confirmation for reopening the basket, it's useless (you can always close it again) * For the close with creating a basket group or no form, it's still needed (as it's not only a confirmation), so i'm OK with the - <label for="createbasketgroup">create a purchase order now?</label> + <label for="createbasketgroup">Attach this basket to a new basket group with the same name</label> benefit = no syspref added. (I'm strongly against multiplicating sysprefs, we already have too many !) IAN = I propose QA failed (but won't set it) (In reply to comment #19) > QA comment > > Reading the patch and thinking of ergonomy rules we try to follow in Koha, I > think this patch addresses a problem, but in a wrong way. > > Ergonomic rule = don't ask for confirmation if you can cancel the operation. > For example, when you add something, you can delete it after, so don't ask "do > you want to add this". Usually, confirmations are added only for deletions. > > So I would say : > * remove the confirmation for reopening the basket, it's useless (you can > always close it again) > * For the close with creating a basket group or no form, it's still needed (as > it's not only a confirmation), so i'm OK with the > - <label for="createbasketgroup">create a purchase order now?</label> > + <label for="createbasketgroup">Attach this basket to a new basket group with > the same name</label> > > benefit = no syspref added. (I'm strongly against multiplicating sysprefs, we > already have too many !) > > IAN = I propose QA failed (but won't set it) This patch just came forth out of Koha not being so ergonomic in this area! I can understand that you do not want unnecessary sysprefs. If it now fails QA after being rebased a number of times and signoff, I suggest to close the patch. Too bad for the time being spent on it. I dont share Pauls aversion to system preferences, I think the configurability of Koha is it's strength not a weakness. So not adding a system preference doesn't add any weight to the argument for me. I see no harm in pushing this patch, but if Ian sees a QA problem with it, I would reconsider. Chris = What I tried to say is that the syspref is useless: it solves the -real- issue by adding a syspref everybody should/will set to "don't confirm". That's why i'm proposing just to change the wording of the message, and remove the confirmation for reopening the basket. The change on the wording will fix one of the problem, removing the message will fix the other one, and no one will complain about the "do you confirm reopening the basket" The patch should be done in a few minutes, and I'm OK to write it if you want. Marcel = sorry for the time spent on it. (In reply to comment #22) > Chris = What I tried to say is that the syspref is useless: it solves the > -real- issue by adding a syspref everybody should/will set to "don't confirm". > That's why i'm proposing just to change the wording of the message, and remove > the confirmation for reopening the basket. > > The change on the wording will fix one of the problem, removing the message > will fix the other one, and no one will complain about the "do you confirm > reopening the basket" > > The patch should be done in a few minutes, and I'm OK to write it if you want. > > Marcel = sorry for the time spent on it. Will sign your patch if it solves this issue ;) I believe the system preference is a good way of addressing the second half of this bug, the "skip confirmation when closing" part. Let users determine if adding the closed basket to a basketgroup is part of their Acquisitions workflow or not. I would agree that the confirmation for the reopening of a basket should be removed, but that is outside the scope of this bug report. At least with this patch confirmations going both ways are consistent. I'm marking this patch as Passed QA. For the removal of the basket reopen confirmation, please open another bug report. Please note that BOTH patches, the code and the syspref installation, have Passed QA; forgot to mention that before clicking 'Save changes'. Pushinated, please test Created attachment 4955 [details] [review] Installation patch for 3.4.X Rebased for 3.4.X Two months passed: closing it myself.. |