- Koha-devel - lists.koha-community.org

[Bug 398] New: Authorised values - spelling & grammer
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=398 Summary: Authorised values - spelling & grammer Product: Koha Version: CVS Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Parameters AssignedTo: paul.poulain(a)free.fr ReportedBy: Ilacis(a)chillco.com QAContact: koha-devel(a)lists.sourceforge.net /cgi-bin/koha/admin/authorised_values.pl Currently: When you define the MARC subfield structure, you can link a subfield to a authorised-value category. When the user ask for adding of modifying a biblio, the subfield is not entered through a free field, but though a list of authorised values Suggested: When you define the MARC subfield structure, you can link a subfield to an authorised-value category. When the user adds or modifys a biblio, the subfield is not entered through a free field, but though a list of authorised values. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 397] New: Itemtypes capitalization
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=397 Summary: Itemtypes capitalization Product: Koha Version: CVS Platform: PC OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Parameters AssignedTo: paul.poulain(a)free.fr ReportedBy: Ilacis(a)chillco.com QAContact: koha-devel(a)lists.sourceforge.net cgi-bin/koha/admin/itemtypes.pl loan length - Loan length charge - Charge ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 396] New: Menu Bars - top and bottom should match
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=396 Summary: Menu Bars - top and bottom should match Product: Koha Version: CVS Platform: PC OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Parameters AssignedTo: paul.poulain(a)free.fr ReportedBy: Ilacis(a)chillco.com QAContact: koha-devel(a)lists.sourceforge.net This affects all of the Koha Intranet. There are top and bottom menu bars that are ordered differently and have different names. The top menu bar says: Home Catalogue Members Acquistion (it should be plural - Acquistions) Marc (should be caps - MARC) Ciculation Reports Parameters About The bottom menu says: Home || Circulation || Catalogue || Members || Acquisitions || Reports || System Parameters || Help If both top and bottom menus are to be used they should match exactly in what they say. See bug #391 regarding the Help link. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 395] New: Category Page Clean-up
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=395 Summary: Category Page Clean-up Product: Koha Version: CVS Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Parameters AssignedTo: paul.poulain(a)free.fr ReportedBy: Ilacis(a)chillco.com QAContact: koha-devel(a)lists.sourceforge.net /cgi-bin/koha/admin/categorie.pl /cgi-bin/koha/admin/categorie.pl?op=add_form&categorycode= Enrollment not enrolment Note: currently add member ignores these parameters - see bug 225 - if they are not meant work in the current version they should be commented out Enrollment period - this is how long your library card is good for - so input form field size should reflect that - 2 digits max Note: this takes an integer so cannot issue a library card for less than a year Upperage limit - this is the maximum age allowed for a child's card (where the card has a guarantor - there is no restriction on the kind of materials that can be checked out.) This is a required field - so that when creating adult categories one has to guess at the maximum age that your patrons will live to. Should this be required? The form field should allow for 3 digits max which you will need to enter a non-child category. Age required - form field should allow for 2 digits max (to get a card) Fine - this is deprecated - it was the tyoe of fine charged to patrons - can this be commented out? Bulk - this is deprecated - can this be commented out? Enrollment fee - it is output with 6 zeros following the decinal - can that be changed to 2 0's following the decimal - I underestand that a fee could be 14000 dong if this was used in Vietnam but I am not familiar with any currency that goes in the 100 thousands the other way. Overdue notice required - to separate regular patrons from people like librarians that don't require an over due notice. If this is currently used it should be a check-box or a radio button since the choices are Yes/No. User should not have to enter a 0 or a 1. Issue limit - field size should allow 2 digit max? Reserve fee - see above regarding 0's past the decimal ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 297] Images missing on View Account page
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=297 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

2 1

[Bug 196] user input not checked for HTML tags
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=196 paul.poulain(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |LATER ------- Additional Comments From paul.poulain(a)free.fr 2003-04-24 03:05 ------- The solution is to parse all templates and add "ESCAPE='HTML'" everywhere : CC of the HTML::Template doc : <TMPL_VAR NAME="PARAMETER_NAME"> The <TMPL_VAR> tag is very simple. For each <TMPL_VAR> tag in the template you call $template->param(PARAMETER_NAME => ``VALUE''). When the template is output the <TMPL_VAR> is replaced with the VALUE text you specified. If you don't set a parameter it just gets skipped in the output. Optionally you can use the ``ESCAPE=HTML'' option in the tag to indicate that you want the value to be HTML-escaped before being returned from output (the old ESCAPE=1 syntax is still supported). This means that the ``, <, >, and & characters get translated into ", <, > and & respectively. This is useful when you want to use a TMPL_VAR in a context where those characters would cause trouble. Example: <input name=param type=text value="<TMPL_VAR NAME="PARAM">"> If you called param() with a value like sam``my you'll get in trouble with HTML's idea of a double-quote. On the other hand, if you use ESCAPE=HTML, like this: <input name=param type=text value="<TMPL_VAR ESCAPE=HTML NAME="PARAM">"> You'll get what you wanted no matter what value happens to be passed in for param. You can also write ESCAPE=``HTML'', ESCAPE='HTML' and ESCAPE='1'. Substitute a 0 for the HTML and you turn off escaping, which is the default anyway. There is also the ``ESCAPE=URL'' option which may be used for VARs that populate a URL. It will do URL escaping, like replacing ' ' with '+' and '/' with '%2F'. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 394] New: Reserve process doesn't require pickup branch
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=394 Summary: Reserve process doesn't require pickup branch Product: Koha Version: 1.9.2 Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: OPAC AssignedTo: paul.poulain(a)free.fr ReportedBy: oleonard(a)athenscounty.lib.oh.us QAContact: koha-devel(a)lists.sourceforge.net The reserve process allows reserves to be placed without requiring a pickup branch to be chosen. This problem was discovered when using the default english template. The value inserted into the branchcode column of the reserves table is 'sele'. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

RE: [Koha-devel] Intranet Security
by Dave Thorne 23 Apr '03

23 Apr '03

1 0

[Bug 130] Branch data entry form has unlabelled check box
by bugzilla-daemon＠wilbur.katipo.co.nz 23 Apr '03

23 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=130 ------- Additional Comments From Ilacis(a)chillco.com 2003-04-24 02:20 ------- English ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

RE: [Koha-devel] Intranet Security
by Anthony W Youngman 23 Apr '03

23 Apr '03

Looking at the way it works (as posted by Paul), I was struck that it didn't seem to have the ability to delete anywhere. Maybe that's deliberate - you want to keep records of what you had, and there's a flag to say the record is dead? I haven't actually used Koha at all (I ended up following this list by accident - I'm a database specialist). And I hadn't seen Paul's message before I responded. But what I was thinking, for easy admin, is a box with "read", "write", "add", "delete" as the column headings, and the various objects (branch, book, biblio, whatever) as the rows. You could call this up for groups, users, or default, and then you tick what's allowed. So the administrator can create groups called "borrower", "desk clerk", "librarian" or whatever and give them permission sets. The critical thing here is that by making the groups equal to job function (eg desk clerk looks after borrowing, librarian looks after the collection), you could allocate the correct permissions for the task, and if a person has multiple roles, you just make them a member of multiple groups. Because permissions are additive at the group level, somebody in both groups could do both things. But, if the administrator decided to add a user-acl for a particular user, the creation would initially load the screen with their group rights. Let's assume we have a user who needs access to a section, but rarely uses it and has a habit of making mistakes. You could remove their write-access. Or you want a desk clerk to do a subset of librarian functions, but don't want them to be able to change anything - so you just give them "add" access. This would be great for getting someone inexperienced to add biblios for example - they can add but they can't change what's already there. This again fits in with my administrator paranoias - it's very rare for people to damage things deliberately (I have met that :-( but quite common to make mistakes. Our corporate philosophy is "read everywhere, write only in your own department" and that is specifically to prevent ACCIDENTAL damage to other people's data. ACLs really are great for this. The problem I see with the flag setup that Paul has posted is that it does not look transitively complete to me. I would separate being able to add data from being able to change data. And can you set it per group, or do you have to set it per user? It looks to me very practical for its purpose. It's just that I've learnt from experience that it always pays to solve the general problem and let the specific problem solve itself, rather than tackle the specific problem directly. This looks to me like a specific-problem-solution :-( The main thing I hate about the NT scheme is that *all* permissions are additive by default. So if a user has rights by virtue of the group they belong to then you can't take them away :-( This scheme (like Primos) says "if you hit a user acl then group acls are *ignored*! Cheers, Wol -----Original Message----- From: Dave Thorne [mailto:mmmbena1@hotmail.com] Sent: 23 April 2003 13:11 To: Anthony W Youngman; koha-devel(a)lists.sourceforge.net Subject: RE: [Koha-devel] Intranet Security > Far better (if possible) to look at ACLs. And don't copy the NT way of > doing it. What would you argue as the negative aspects of grouped permissions in the scope of Koha(whether NT used something similar or not)? > I would probably have four permissions per object, namely add, delete, > read and write (need rw to edit, ad to move). And I don't know how many > objects - presumably branches, books, and loans to name the obvious. I too am a great fan of ACLs. I use and administer linux every day and the scope and flexibility that the ACL permission framework affords is beyond anything else I have seen in other operating systems. My misgivings about using it in this context would be how user friendly it would be. Assuming we want to make the experience of administering Koha as simple and as straight forward as possible, I would see group permissions as greatly simplifying that process. In saying this, however much practical knowledge of ACLs I have, I have never implemented them in any solution of mine. Could you explain (for my benefit more than anyone else's) how you would envisage the permissions section to work? Both from the point of view of initial setup of the ACLs and of the day to day user admin? :o) Dave -----Original Message----- From: Dave Thorne [mailto:mmmbena1@hotmail.com] Sent: 19 April 2003 03:14 To: koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] Intranet Security I must say that although the library I am speaking on behalf of would not need more than one layer of security abstraction, for larger systems I believe it would be necessary. In order to make Koha as 'marketable' as possible (in the least capitalistic way) such a permissions based user environment would be greatly preferred, giving more configurability (and therefore leaving Koha available to a wider potential user base) which can only be a good thing. As long as the extra work required to manage such permissions is kept to an absolute minimum so as not to impinge on the experience of smaller libraries we should be on to a winner. How about permission groups? Then you could set up 'desk clerk' and 'librarian' as two seperate groups (or user types) with the associated permissions set to the groups, and simply add users to or remove them from these groups. The act of setting every possible permission for a new user is then made a thousand fold easier. Although I admit I have not yet looked at the user administration section in detail, I can't imagine it would take much to implement. Any comments? Dave ----Original message from jferraro follows---- I have been thinking about the current intranet security setup whereby any staff member can access any part of the intranet. Is this the policy in the libraries that are currently using Koha? It may be important to some of the larger systems (where more than a dozen people are using the intranet) to increase the levels of password protection. My concern is less of a control issues and more of an "oops I just deleted our main branch" issue. Even adding one more layer by seperating the admin from the normal staff functions might be useful. Even better, maybe users could be added and given "permission" to access parts of the intranet. What does everyone think? Joshua _____ Want your email in a hurry? Get Hotmail direct to your mobile ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel << InterScan_Disclaimer.txt >> _____ Express yourself with cool emoticons. Get MSN Messenger <http://g.msn.com/8HMKENUK/2746> today.

1 0