Re: [OPEN-ILS-DEV] ***SPAM*** OpenSRFEvergreen Redhat Patches

2010-03-10 Thread Lee Dickens




Here is the documentation that corresponds to the redhat patches:

  http://open-ils.org/dokuwiki/doku.php?id=redhat_opensrf_trunk
  http://open-ils.org/dokuwiki/doku.php?id=redhat_evergreen_trunk
  http://open-ils.org/dokuwiki/doku.php?id=redhat_evergreen_cluster

I would love to see someone try this on CentOS as it has only been
tested on Redhat. If you do try it on CentOS, remember to use "centos"
instead of "rhel" in your make -f command when installing the
prerequisites.

Thanks,
Lee Dickens


Lee Dickens wrote:
Greetings,
  
  
Attached you will find patches for OpenSRFEvergreen that add
Redhat support. These patches have been tested on RHEL 32 bit and 64
bit. Theoretically this should also provide support for CentOS;
however, this functionality has not been tested. 
My patches rely on the rpmforge repository for perl modules, and the
pgdg repository for updated postgresql packages. I am sure there are
plenty of things that I could be doing better. Any
advice/criticism/bugfixes will be greatly appreciated.
  
  
I am currently working on wiki documentation and hope to have it
uploaded shortly. I will post a link when it is available.
  
  
Thanks,
  
Lee Dickens
  
  
  
Equinox will be at the 2010 Public Library Association
  
Conference in Portland, Oregon, March 23-27.
  
Please come by and see us in booth #1407!






Equinox will be at the 2010 Public Library Association
Conference in Portland, Oregon, March 23-27.
Please come by and see us in booth #1407!



Re: [OPEN-ILS-DEV] Suggested Patch: Block Renews for Holds

2010-03-10 Thread Dan Wells
Hello again,

Attached you will now find two versions of the patch, one for rel_1_6_0 and one 
for trunk.  The rel_1_6_0 version only differs from the first version in adding 
a new matching permission to the data seed file.  The trunk version populates 
the config.org_unit_setting_type table rather than the org_unit_settings.xhtml 
file.  I have less confidence in the trunk version due to lack of experience, 
and the permissions table adds should be double-checked in both cases, as trunk 
and rel_1_6_0 populate these tables quite differently.

Thanks,
Dan

 On 3/10/2010 at 1:26 PM, Dan Wellsd...@calvin.edu (Dan Wells) wrote:
 Hello all,
 
 The attached patch is a very simple means of allowing an option for the 
 blocking of renews if an item is targeted for a hold.  There was some 
 discussion on IRC about the 'best' way to do this, but other ways (in my 
 opinion) ended up as just too far-reaching for what should be a simple 
 feature.
 
 This is tested and in production at our in-db-circ site, but I think it will 
 work for script-based-circ as well.  The patch targets rel_1_6_0.
 
 Thanks,
 Dan
 
 =
 Developer's Certificate of Origin 1.1
 
 By making a contribution to this project, I certify that:
 
 (a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
 
 (b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
 
 (c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
 
 (d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
 
 Signed-off-by: Daniel B. Wells
 =
 
 



block_renews_for_holds-rel_1_6_0-with-seed.diff
Description: Binary data


block_renews_for_holds-trunk.diff
Description: Binary data


[OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Grant Johnson
I am having trouble with the Mac staff client in 1.6.0.0 and 1.6.0.2
Most things seem to work fine.

BUT...

If I choose to Show Item Details  of a record Item I get an error...

FIXME:  util.widgets.set_text doesn't know how to handle treecol

Clicking OK   10 times allows the display to appear.
But the display of the Item Summary is chopped off at the bottom.

I have tried copying the Build folder from a Windows client  into the
appropriate folder in the Mac Package. 
Same thing.

2 Questions:

1) Could it be an Xulrunner issue?
2) Would building a fresh client on the server and deploying it to Mac
help?



F. Grant Johnson
  Systems Coordinator
  Robertson Library, University of Prince Edward Island
  902-566-0630(w),  902-393-4920(c)






Re: [OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Benjamin Shum
Hey Grant,

We've seen that error pop up on our Mac staff clients (and Linux ones) as well 
since 1.6.0.0.  Our current Mac client users are using a 1.6.0.2 that I 
packaged together using a fresh source from our production server before we 
went live.

I asked once about it awhile back and it was mentioned in this IRC log:  
http://www.openevergreen.net/irc_logs/evergreen/2009-12/%23evergreen.04-Fri-2009.log
  It looked like there were some conflicting id collisions among the xul 
elements according to phasefx.

With our recent migration work we'd been doing, I haven't had a change to come 
back to this problem yet, but I'll poke around to see what else I can gather.

-- Ben

On Mar 10, 2010, at 3:50 PM, Grant Johnson wrote:

 I am having trouble with the Mac staff client in 1.6.0.0 and 1.6.0.2
 Most things seem to work fine.
 
 BUT...
 
 If I choose to Show Item Details  of a record Item I get an error...
 
 FIXME:  util.widgets.set_text doesn't know how to handle treecol
 
 Clicking OK   10 times allows the display to appear.
 But the display of the Item Summary is chopped off at the bottom.
 
 I have tried copying the Build folder from a Windows client  into the
 appropriate folder in the Mac Package. 
 Same thing.
 
 2 Questions:
 
 1) Could it be an Xulrunner issue?
 2) Would building a fresh client on the server and deploying it to Mac
 help?
 
 
 
 F. Grant Johnson
  Systems Coordinator
  Robertson Library, University of Prince Edward Island
  902-566-0630(w),  902-393-4920(c)
 
 
 
 

Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070 ext. 113



Re: [OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Bill Ott

Benjamin Shum said the following on 03/10/2010 04:11 PM:

Hey Grant,

We've seen that error pop up on our Mac staff clients (and Linux ones) as well 
since 1.6.0.0.  Our current Mac client users are using a 1.6.0.2 that I 
packaged together using a fresh source from our production server before we 
went live.

I asked once about it awhile back and it was mentioned in this IRC log:  
http://www.openevergreen.net/irc_logs/evergreen/2009-12/%23evergreen.04-Fri-2009.log
  It looked like there were some conflicting id collisions among the xul 
elements according to phasefx.
   



I've seen these as well.  Looking into it deeper is on my to-do list, 
but a quick kludge is to comment out line 316 (?) server/util/widgets.js


It looks pretty benign.


Re: [OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Bill Ott

Bill Ott said the following on 03/10/2010 04:15 PM:

Benjamin Shum said the following on 03/10/2010 04:11 PM:

Hey Grant,

We've seen that error pop up on our Mac staff clients (and Linux 
ones) as well since 1.6.0.0.  Our current Mac client users are using 
a 1.6.0.2 that I packaged together using a fresh source from our 
production server before we went live.


I asked once about it awhile back and it was mentioned in this IRC 
log:  
http://www.openevergreen.net/irc_logs/evergreen/2009-12/%23evergreen.04-Fri-2009.log  
It looked like there were some conflicting id collisions among the 
xul elements according to phasefx.



I've seen these as well.  Looking into it deeper is on my to-do list, 
but a quick kludge is to comment out line 316 (?) server/util/widgets.js


It looks pretty benign.



I'm feeling a little dirty for suggesting just commenting out error 
reporting.  The following would just quiet the noted error.




Index: widgets.js
===
--- widgets.js(revision 15779)
+++ widgets.js(working copy)
@@ -312,6 +312,9 @@
 case 'textbox' :
 n.value = t; n.setAttribute('value',t);
 break;
+case 'treecol' :
+// do something?
+break;
 default:
 alert(FIXME: util.widgets.set_text doesn't know how to 
handle  + n.nodeName);

 break;




Re: [OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Jason Etheridge
 If I choose to Show Item Details  of a record Item I get an error...

 FIXME:  util.widgets.set_text doesn't know how to handle treecol

Hey Grant, could  you try the trunk version of server/cat/copy_summary.xul?

Or alternately, apply this changeset:
http://svn.open-ils.org/trac/ILS/changeset/15162

 2 Questions:

 1) Could it be an Xulrunner issue?

I think it's a flaw/ambiguity in the code that the Mac version of
xulrunner exposes.

Basically, we have elements with the same id attribute (which should
be illegal), and the Windows version of xulrunner is choosing one, and
the Mac version is choosing the other.

 2) Would building a fresh client on the server and deploying it to Mac help?

You should be able to fix this solely on the server side.  If that
changeset works, I'll backport it all the way to rel_1_6_0.

Thanks!

-- 
Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  ja...@esilibrary.com
 | web:  http://www.esilibrary.com

Please join us for the Evergreen 2010 International Conference!
It is being held April 20 - 23, 2010 at the Amway Grand Hotel and
Convention Center, Grand Rapids, Michigan.
http://www.evergreen2010.org/


Re: [OPEN-ILS-DEV] Mac Staff Client

2010-03-10 Thread Benjamin Shum
To Jason,

I copied the trunk version of server/cat/copy_summary.xul to one of our test 
servers and it seemed to take the change well.  My Mac client is now able to 
open the Item Details (Copy Summary) without that error message popping up 
everywhere.  So it looks like changing all those id's helped.

-- Ben

On Mar 10, 2010, at 4:52 PM, Jason Etheridge wrote:

 If I choose to Show Item Details  of a record Item I get an error...
 
 FIXME:  util.widgets.set_text doesn't know how to handle treecol
 
 Hey Grant, could  you try the trunk version of server/cat/copy_summary.xul?
 
 Or alternately, apply this changeset:
 http://svn.open-ils.org/trac/ILS/changeset/15162
 
 2 Questions:
 
 1) Could it be an Xulrunner issue?
 
 I think it's a flaw/ambiguity in the code that the Mac version of
 xulrunner exposes.
 
 Basically, we have elements with the same id attribute (which should
 be illegal), and the Windows version of xulrunner is choosing one, and
 the Mac version is choosing the other.
 
 2) Would building a fresh client on the server and deploying it to Mac help?
 
 You should be able to fix this solely on the server side.  If that
 changeset works, I'll backport it all the way to rel_1_6_0.
 
 Thanks!
 
 -- 
 Jason Etheridge
 | VP, Tactical Development
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  ja...@esilibrary.com
 | web:  http://www.esilibrary.com
 
 Please join us for the Evergreen 2010 International Conference!
 It is being held April 20 - 23, 2010 at the Amway Grand Hotel and
 Convention Center, Grand Rapids, Michigan.
 http://www.evergreen2010.org/

Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070 ext. 113