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

[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

TMPL_IF question
by Owen Leonard 23 Apr '03

23 Apr '03

If there's a variable <TMPL_VAR NAME="numrecords">, can you say something like: <TMPL_IF "numrecords" greater than 0> ... lots of records </TMPL_IF>? -- Owen

3 2

Re: [Koha-devel] KohaAdminEmailAddress system preference is not set?
by Ingrid Lacis 23 Apr '03

23 Apr '03

You need to add the variable yourself. Under parameters go to system preferences. Click the add icon. Add variable KohaAdminEmailAddress and then the email address of the person at the library who would be validating patron change of address requests. Ingrid >When I click the 'Update Record' link (cgi-bin/koha/opac-userupdate.pl)in >the >member's home screen in the OPAC, I get an error message that says >"KohaAdminEmailAddress system preference is not set. Please visit the >library >to update your user record." Is this just a matter of a value missing from >our >system preferences table? > > -- Owen > > > >------------------------------------------------------- >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 _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

RE: [Koha-devel] Open Source or Free Software?
by Anthony W Youngman 23 Apr '03

23 Apr '03

Why not call it "Libre for Libraries"? :-) Cheers, Wol -----Original Message----- From: MJ Ray [mailto:markj@cloaked.freeserve.co.uk] Sent: 22 April 2003 12:44 To: Chris Cormack Cc: koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] Open Source or Free Software? On 2003-04-22 12:12:17 +0100 Chris Cormack <chris(a)katipo.co.nz> wrote: > In this case Rachel was meaning Free as in free beer. OK, fair enough, but that's not free software, as was being discussed. [...] > The easiest way to do this on the front page of the koha site, in a > simple > way that most people understand was to use the term Open Source. People don't understand "Open Source" and the OSI definition is far too long to be memorable by the average human brain unless they are a specialist OSI-advocate. The fuzzy concept of "open source" is part of the reason why the confusion marketing tactics of certain free software opponents are so successful. > Having said that, as I said before I refer to Koha as Free Software, > or Open > Source, depending on who im talking to. Which I think is the best > solution. I disagree, as you've probably gathered. ;-) Very few non-specialist audiences understand either term, so an explanation is useful and I go for the clearest simplest explanation, honed over 20 years. > As long as people understand its licensed under the GPL and what that > entails .. i dont really mind what its called :-) Well, yes, the important thing is the concept, not the brand, isn't it? I agree entirely, so suggest that people reject the brand-as-king "Open Source" term. -- MJR http://mjr.towers.org.uk/ IM: slef(a)jabber.at This is my home web site. This for Jabber Messaging. How's my writing? Let me know via any of my contact details. ------------------------------------------------------- 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

1 0

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

23 Apr '03

Far better (if possible) to look at ACLs. And don't copy the NT way of doing it. The system I admired had individual (named) permissions, group permissions, and default. If it hit a named permission, that was it. That was what you got. Otherwise it added up all your group permissions. And if it couldn't find any group permissions, then you got the default. 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. The other thing this system had was the super-ACL, which was set outside of the standard ACL setup, and over-rode it. I regularly did "super user = no rights" on the live disk pack while I was testing something dangerous :-) Cheers, Wol -----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 <http://g.msn.com/8HMLENUK/2740> 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

1 0

[Bug 354] Acquisitions Link in Menu always goes to full (normal) acquistions
by bugzilla-daemon＠wilbur.katipo.co.nz 22 Apr '03

22 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=354 Ilacis(a)chillco.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From Ilacis(a)chillco.com 2003-04-23 12:57 ------- Now when preferences are set to SIMPLE clicking on Aquistions will instead take you to the MARC page though the menu bar will say Aquistions. If you change your preferences to NORMAL you can get both the MARC and the Aquistions pages HOWEVER the menu bar will be hi-lighted to Aquistions when you are in MARC. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

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

22 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=130 ------- Additional Comments From a.c.li(a)ieee.org 2003-04-23 12:41 ------- Sorry for disappearing for so long. What language are you using? ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 365] On the parameters page, 'stopwords' appears twice
by bugzilla-daemon＠wilbur.katipo.co.nz 22 Apr '03

22 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=365 Ilacis(a)chillco.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From Ilacis(a)chillco.com 2003-04-23 12:36 ------- He is referring to version 1.2.3 not 1.9.2 - I recall seeing stopwords twice also in that version. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

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

22 Apr '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=130 ------- Additional Comments From Ilacis(a)chillco.com 2003-04-23 12:26 ------- cgi-bin/koha/admin/branches.pl I just - today April 23rd - downloaded the most recent Koha from CVS and I get this still Your template is out of date (bug 130) Your template is out of date (bug 130) by the unlabeled checkbox. Now in the unpublished documentation (Manual v 1.2) it talks about different categories in the library branches to be checked off - Issuing - if the branch can issue books, Permanent - Return - if an item of this branch must be returned at the home branch, Home - to set this branch as the home branch, Current to set this as the current branch. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0