[Koha-bugs] [Bug 7276] member entry Performance improvement
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7276 --- Comment #13 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-10 09:13:33 UTC --- (In reply to comment #12) OK, I undestand what I missed: cleaning the variable is necessary, otherwise, it will stay forever in your variable, which is bad. It has nothing to do with memcache PS: maybe we should write guidelines to manage persistent variables Probably a good idea. PS2: with a persistent model, will memcache still be usefull ? Yes, even with persistence, threads die after a while and respawn. So it is still useful. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7342] aqbudgets statistics doesn't work when using Authorized values on sort1_authcat or sort2_authcat
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7342 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz --- Comment #5 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-10 09:18:24 UTC --- Hi Alex A little thing is this patch, that will cause the tests to fail, is the address for the FSF is wrong It is # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. (check mainpage.pl in master). I wont fail QA it for that, but it will need either a follow up or Paul to fix when he pushes it. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7342] aqbudgets statistics doesn't work when using Authorized values on sort1_authcat or sort2_authcat
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7342 --- Comment #6 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-10 09:24:23 UTC --- Created attachment 6696 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6696 Bug 7342: Follow up fixing FSF address and adding use warnings -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 5543] Date ISO format wrong separator
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5543 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Attachment #6640|0 |1 is obsolete|| --- Comment #4 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-10 09:47:10 UTC --- Created attachment 6697 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6697 Bug 5543 - Date ISO format wrong separator This patch converts the changes in Fridolyn SOMERS patch to T:T and adds an update to the database to correct the description there. Signed-off-by: Chris Cormack chr...@catalyst.net.nz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 5543] Date ISO format wrong separator
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5543 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6803] Removing remote include in MODS xslt
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6803 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Attachment #6636|0 |1 is obsolete|| --- Comment #15 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-10 09:53:08 UTC --- Created attachment 6698 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6698 Bug 6803: Replacing remote XSL include Replacing remote include by local one. This resolves possible connectivity issues (see Bugzilla comments). Should theoretically be safer and faster too. December 7, 2011: Rebased and included nbsp entity definition (bug 7141). Signed-off-by: Chris Cormack chr...@catalyst.net.nz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6803] Removing remote include in MODS xslt
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6803 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 1633] Add ability to take book cover images from local img db
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1633 --- Comment #5 from Jared Camins-Esakov jcam...@cpbibliography.com 2011-12-10 19:27:24 UTC --- Created attachment 6699 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6699 Bug 1633: Add support for uploading images to Koha A frequently-requested feature for Koha, especially by special libraries, is the ability to upload local cover images into Koha. This patch adds that ability. This counter-patch builds on the work by Koustubha Kale at Anant Corporation, but adds the following additional features: 1. Moves the code for handling image retrieval/saving into the Koha namespace 2. The ability to have multiple cover images for a biblio 3. Handling for full size (800x600) and thumbnail-size (200x140) images 4. A separate image viewer page 5. Javascript-based handling of cover image placement for the cover images in the OPAC (as opposed to static img / tags embedded into pages) 6. Local cover display in the staff client 7. Uploading images directly from the record view How to use/test : Assign user permission to the user Tools (upload_local_cover_images Upload local cover images). In order to upload local images, login to the staff client. Go to Home › Tools › Upload Cover Images. Here you can upload cover images either singly or in bulk in the form of a zip file. If uploading singly, click on image file, browse the image from your local disk, type in the biblio number of the catalogue entry and press upload. If uploading in bulk as a zip file, the zip file must contain (in addition to cover images) one text file named either datalink.txt OR idlink.txt. This file should have mapping of biblionumber to image file name in the zip one per line with comma or tab as delimiters. For example: 1, scanned_cover_image_of_bib_no_1.jpg 2, scanned_cover_image_of_bib_no_1.jpg Cover images will be resized to a large image of 800x600 and a thumbnail of 200x140. Depending on the setting of AllowMultipleCovers, it is possible to upload multiple images for a single bibliographic record. However, even if multiple covers are permitted, you have the option of replacing the existing covers by checking the Replace existing covers option on the upload screen. 1. The patch adds a menu link in Tools from where you can upload local cover images 2. It adds a user permission to enable access control to this menu item under Tools 3. It adds a system preference OPACLocalCoverImages under Enhanced Content. This needs to be turned on to show local cover images in OPAC. Once you have uploaded local images, if you search for the biblio, the local cover should show up in search as well as search detail pages in the OPAC, and the details view in the Intranet. Koustubha Kale is working on another patch which will allow us to set a cover image source priority in system preferences, and which will then gracefully fail over to the next source if image is not available from the first choice source. Detailed test plan: 1. Install update (database updates are in installer/data/mysql/atomicupdate/local_cover_images.pl) 2. Enable LocalCoverImages and OPACLocalCoverImages in the Enhanced content preferences screen 3. Upload an image of type GIF, JPEG, PNG, or XPM either from the Local Cover Image tool and choosing Image file as its type and entering a valid biblionumber, or by viewing a record and clicking the Upload Image option under the Edit button in the toolbar 4. View the record in the Intranet and OPAC. The image should show up directly in OPAC search results and details, and there should be an Images tab on both the Intranet and the OPAC detail view 5. Upload another image and attach it to the same bibliographic record. 6. Confirm that the new image (only) shows up in the OPAC and Intranet 7. Change the AllowMultipleCovers to Allow in the Enhanced content preferences screen 8. Add several images to a bibliographic record 9. Confirm that they all show up in the Images tab on the Intranet and OPAC and only one shows up in the main display in the OPAC details and search results pages 10. Create a zip file containing at least one image and a text file idlink.txt with one or more lines that looks like this: 1, filename.jpg Replace the '1' with a valid biblionumber, and 'filename.jpg' with the name of the image file you are adding to the zip file 11. Upload the zip file from the Local Cover Image tool (being sure to choose zip file as the filetype) 12. Check that the image(s) have been attached to the appropriate bibliographic record(s) Special thanks to Koustubha Kale and Anant Corporation for the initial implementation of local cover images, and to Chris Nighswonger of Foundation Bible College for his prior work on patron images. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are
[Koha-bugs] [Bug 6292] Overdue notices have a bug when multiple overdues exist
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6292 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Attachment #5221|0 |1 is obsolete|| --- Comment #20 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-11 00:03:36 UTC --- Created attachment 6700 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6700 Bug 6292 : Followup 2. several letters where generated if a borrower had overdues with different due_date triggering the same level This patch fixes the SQL request giving the list of borrowers Signed-off-by: Chris Cormack chr...@catalyst.net.nz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6292] Overdue notices have a bug when multiple overdues exist
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6292 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6800] Koha authentication should handle proxies better
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz Patch Status|Needs Signoff |Does not apply --- Comment #3 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-11 00:06:39 UTC --- Jared, if you have time, could you reformat the patch, we no longer need all the other sysprefs just the english one. (It won't currently apply until that is done) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6151] IndependantBranches and HomeOrHoldingBranchReturn can prevent items from being checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6151 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Attachment #6497|0 |1 is obsolete|| --- Comment #4 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-11 00:13:19 UTC --- Created attachment 6701 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6701 Bug 6151: Add AllowReturnToBranch system preference In order to solve the issue of IndependantBranches being incompatible with HomeOrHoldingBranchReturn, this patch changes the mechanism by which the question can I return this material here? is answered. Before, the conditions were if IndependantBranches is on, and this branch isn't HomeOrHoldingBranchReturn for the item, then no, otherwise yes. Now, the question is answered by consulting CanBookBeReturned (new subroutine) New system preference: AllowReturnToBranch Possible values: - anywhere (default for new installs, and for existing systems with IndependantBranches turned off) - homebranch - holdingbranch (which is also the issuing branch in all normal circumstances) - homeorholdingbranch (default for existing systems with IndependantBranches turned on) New subroutine: CanBookBeReturned Input: $item hash (from GetItems), and $branchcode Output: 0 or 1 to indicate allowed or not, and an optional message if not allowed. Message is the 'correct' branchcode to return the material to To Test: 1. Install patch and new syspref 2. Check that default value of the preference: - if IndependantBranches was OFF at install time, should be 'anywhere' - if IndependantBranches was ON at install time, should be 'homeorholdingbranch' Case: 'anywhere' 1. Checkout a Library A book at Library A. Return at Library A should be successful 2. Repeat step 1, returning to Library B. Return should be successful 3. Checkout a Library A book at Library B. Return to A should be successful 4. Repeat step 3 with Library B and Library C Case: 'homebranch' 1. Checkout a Library A book at Library A. Return at Library A should be successful 2. Repeat step 1, returning to Library B. Return should FAIL (returning message to return at A) 3. Checkout a Library A book at Library B. Return to Library A should be successful 4. Repeat step 3 with Library B and Library C. Both should FAIL (returning message to return at A) Case: 'holdingbranch' 1. Checkout a Library A book at Library A. Return at Library A should be successful 2. Repeat step 1, returning to Library B. Return should FAIL (returning message to return at A) 3. Checkout a Library A book at Library B. Return to A should FAIL (returning message to return at B) 4. Repeat step 3 with Library B. Return should be successful 5. Repeat step 3 with Library C. Return should FAIL (returning message to return at B) Case: 'homeorholdingbranch' 1. Checkout a Library A book at Library A. Return at Library A should be successful 2. Repeat step 1, returning to Library B. Return should FAIL (returning message to return at A) 3. Checkout a Library A book at Library B. Return to A should be successful 4. Repeat step 3 with Library B. Return should be successful 5. Repeat step 3 with Library C. Return should FAIL (returning message to return at A) Signed-off-by: Chris Cormack chr...@catalyst.net.nz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6151] IndependantBranches and HomeOrHoldingBranchReturn can prevent items from being checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6151 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7299] ILSDI HoldItem service does't set the itemnumber in reserves table
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7299 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz --- Comment #2 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-11 00:21:27 UTC --- Hmmm, this now also passes in the biblionumber as biblioitemnumber ... which may not always be the same thing. Luckily because it is constraint 'a' it isn't used. But I wonder if we should remove it so it isn't confusing in future? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7127] Templates must be valid XHTML
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7127 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added Attachment #6342|0 |1 is obsolete|| --- Comment #2 from Chris Cormack ch...@bigballofwax.co.nz 2011-12-11 00:26:43 UTC --- Created attachment 6702 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6702 Bug 7127 - Templates must be valid XHTML Signed-off-by: Chris Cormack chr...@catalyst.net.nz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7127] Templates must be valid XHTML
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7127 Chris Cormack ch...@bigballofwax.co.nz changed: What|Removed |Added CC||ch...@bigballofwax.co.nz Patch Status|Needs Signoff |Signed Off -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 6800] Koha authentication should handle proxies better
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800
Jared Camins-Esakov jcam...@cpbibliography.com changed:
What|Removed |Added
Attachment #5185|0 |1
is obsolete||
--- Comment #4 from Jared Camins-Esakov jcam...@cpbibliography.com 2011-12-11
00:29:19 UTC ---
Created attachment 6703
-- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6703
Bug 6800: Handle X-Forwarded-For headers
Previously Koha always used the remote address for its sessions. This is a
problem where a sizable percentage of sessions are being routed through the
same proxy (for example, in the case of load balancers or reverse proxies,
or even a corporate proxy). This commit adds support for pulling the
client's IP address out of the X-Forwarded-For HTTP header, so that sessions
will be keyed to the client and not the proxy.
Although X-Forwarded-For can be spoofed, in situations where all clients
would have the same immediate REMOTE_ADDRESS (e.g. load balancing, reverse
proxy, corporate firewall), using X-Forwarded-For seems the lesser of two
evils (if you're running the proxy, you can guarantee that the most recent
entry in X-Forwarded-For is accurate, hence the behavior when the syspref is
set to require a routable IP).
=== SYSPREFS ===
This commit adds the syspref HandleXForwardedFor with the following options:
* Always use the address of the machine connecting to Koha as the client IP
for authenticated sessions. This is appropriate for configurations with
no reverse proxy or load balancer, and is exactly the same as the
previous behavior.
* Always use the address of the machine with the web browser as the client
IP for authenticated sessions. This is appropriate for configurations
that are contained entirely within a LAN, and therefore non-routable IPs
can be mapped to specific computers.
* Use the first routable address or the address of the last hop before the
proxy as the client IP for authenticated sessions. This is appropriate
for configurations that include a reverse proxy or load balancer exposed
via the public Internet. Anyone connecting through an additional proxy
will have their session linked to that proxy's IP.
=== API CHANGES ===
This commit adds the get_clientip method to C4::Auth to handle
identification of the client IP:
my $clientip = get_clientip($remote_addr, $forwarded_for, $require_routable);
Parses the remote IP address (passed to the function in $remote_addr), the
X-Forwarded-For header (passed to the function in $forwarded_for), and
retrieves the IP address of the client, returning a string representation of
the IP address. If $require_routable is set to first, this function will
always return the most-distant IP address. If $require_routable is set to
routable, this function will choose the first routable IP address in the
list of relays, or the address immediately before the closest proxy. If
$require_routable is set to ignore, this function will always return the
most recent hop (i.e. the remote address). Ignore is the default, if
$require_routable is not set.
=== TESTING INSTRUCTIONS ===
The problem with the current configuration in Koha can be seen by
configuring Koha to listen on 127.0.0.1 and setting up a Squid proxy with
the following configuration options on the same server:
# BEGIN SQUID CONFIGURATION
# The next two lines must go at the top of the squid configuration file:
http_port ${PUBLIC_IP}:80 accel defaultsite=${YOUR_DOMAIN} vhost
cache_peer 127.0.0.1 parent 80 0 no-query originserver name=myAccel
# The next four lines must go AFTER the line acl CONNECT method CONNECT
acl our_sites dstdomain .${YOUR_DOMAIN}
http_access allow our_sites
cache_peer_access myAccel allow our_sites
cache_peer_access myAccel deny all
# END SQUID CONFIGURATION
If you view the session log after connecting via ${PUBLIC_IP}:80, you will
see an entry for 127.0.0.1. This is the default behavior after this patch is
applied as well, but by changing the syspref HandleXForwardedFor to Always
use the address of the originating machine, you can ensure that the IP that
shows up will always be the IP address of the machine with the web browser,
or by setting the syspref to Use the first routable address or address of
last hop before proxy, you can ensure that the IP will always be either the
first routable address or the address of the system connecting to the
reverse proxy. On a LAN, the difference between those two options can be
tested by daisy-chaining a second squid proxy to the first, and connecting
through that.
In addition to these steps for testing, several tests have been added to
confirm that C4::Auth::get_clientip correctly handles valid input.
--
Configure bugmail:
http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
--- You are receiving this mail
[Koha-bugs] [Bug 6800] Koha authentication should handle proxies better
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6800 Jared Camins-Esakov jcam...@cpbibliography.com changed: What|Removed |Added Patch Status|Does not apply |Needs Signoff --- Comment #5 from Jared Camins-Esakov jcam...@cpbibliography.com 2011-12-11 00:30:05 UTC --- Rebased on latest master. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA Contact for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7345] New: Should be possible to export MARC records without private fields
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345 Bug #: 7345 Summary: Should be possible to export MARC records without private fields Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support AssignedTo: jcam...@cpbibliography.com ReportedBy: jcam...@cpbibliography.com QAContact: ian.wa...@bywatersolutions.com At the moment, if you use the opac-export.pl script to obtain a MARC record programmatically from Koha, it includes all private fields and subfields. There should be an option that allows someone to request a records with all private fields (i.e. 9XX, X9X [excepting 490; great going, LC!], and XX9 and subfield $9) removed. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7345] Should be possible to export MARC records without private fields
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345 --- Comment #1 from Jared Camins-Esakov jcam...@cpbibliography.com 2011-12-11 01:25:46 UTC --- Created attachment 6704 -- http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6704 Bug 7345: Enable exporting records sans private fields Add an option for marcstd to the opac-export.pl and catalogue/export.pl scripts. This new format removes all 9XX, X9X, XX9 fields and subfield $9 (with the exception of 490 in flavours of MARC other than UNIMARC). The work is done in C4::Record::marc2marc. Testing plan: 1. Export a record in MARC (Unicode/UTF-8) format as a control 2. In the OPAC, run the following jQuery to add the marcstd option to the UI: $(#export #format).append(option value='marcstd'MARC (no 9xx)/option); 3. Export the same record in MARC (no 9xx) format 4. Compare the two, noticing that any subfield $9 or fields including 9 (other than 490 in flavours of MARC other than UNIMARC) have been removed -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7345] Should be possible to export MARC records without private fields
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7345 Jared Camins-Esakov jcam...@cpbibliography.com changed: What|Removed |Added Priority|P5 - low|PATCH-Sent Status|NEW |ASSIGNED Patch Status|--- |Needs Signoff -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
