The new code should handle that issue.

 

 

 

Line 39 is if (scalar @{$session->get_database->search_sql_ldap($value)})

 

The issue seems to be that the search_sql_ldap function returns a string (“”) if there isn’t a corresponding entry in the database – which is what’s happening in this case. Running the view regeneration verbose from the command line has let me see what user it’s falling over on. The database table in this instance is a custom one which contains “farmed off” users who don’t appear in LDAP any more.

 

 

I’m not surprised the code doesn’t work – it was just typed into the email window as an example.  You were the first to compile it J

 

What’s on line 39?

 

My first guess is that the search_sql_ldap function doesn’t always return an array (this may be they same error that was originally causing the problems).  Try something like this (again, untested):

 

 

my $check;

eval

{

                $check = $session->get_database->search_sql_ldap($value);

}

#check all error conditions

if (

$@ //an error occurred

|| (ref($check ne ‘ARRAY’)) //not an array

                || ! (scalar @{$check}) //empty array returned

                || ! $check->[0]->[0] // no given name

                || ! $check->[0]->[1] // no family name

)

{

                return $session->make_text($value);

}

my $string_build = $check->[0]->[0] . ", " . $check->[0]->[1];

return $session->make_text( $string_build );

 

 

 

 

Right, I’ve tried your code, Adam, but I’m getting a syntax error.

 

The error that’s being generated in the Apache logs is:

 

[Thu Nov 17 15:43:24 2016] [error] [client 10.82.2.59] Can't use string ("") as an ARRAY ref while "strict refs" in use at /usr/share/eprints3/perl_lib/EPrints/MetaField/Authorid.pm line 39, <DATA> line 960.\n

------------------------------------------------------------------

---------------- EPrints System Error ----------------------------

------------------------------------------------------------------

Error in file retrieval: :Apache2 IO write: (103) Software caused connection abort at /usr/share/eprints3/perl_lib/EPrints/Apache/Storage.pm line 258

------------------------------------------------------------------

at /usr/share/eprints3/perl_lib/EPrints/Apache/Storage.pm line 267.

                EPrints::Apache::Storage::handler(Apache2::RequestRec=SCALAR(0x7f11e14e7670)) called at -e line 0

                eval {...} called at -e line 0

 

I’ve had no joy at figuring out where the search_sql_ldap function lives – grepping on our EPrints server seems to be a futile exercise for some unfathomable reason.

 

 

OK, I think the code is confusingly written.  Here’s my take:

 

 

if ($value =~ /^[+-]?\d+$/ ) – if $value is an integer number of some (possibly with a + or – at the beginning

 

if (scalar @{$session->get_database->search_sql_ldap($value)}){ If whatever array the function returns has at least one element

 

my @check = @{$session->get_database->search_sql_ldap($value)}; Call the function again (!) to get the array

 

if(defined($check[0][0]) && defined($check[0][1])) If the first element of the array is an array that has two elements

 

my $string_build = $check[0][0] . ", " . $check[0][1]; //concatenate the two element

 

return $session->make_text( $string_build ); // turn it into a DOM element

 

 

Aside from calling a function that almost certainly does a database query twice (rewrite is probably advisable), there’s nothing in this code that would cause an issue.  My guess is that search_sql_ldap is throwing an exception.  You can go about this two ways:

 

1)       Quick and easy:

 

my @check;

eval

{

                @check = @{$session->get_database->search_sql_ldap($value)};

}

if (

$@ //an error occured

                || ! (scalar @check) //empty array returned

                || ! $check[0][0] // no given name

                || ! $check[0][1] // no family name

)

{

                return $session->make_text($value);

}

my $string_build = $check[0][0] . ", " . $check[0][1];

return $session->make_text( $string_build );

 

2)       The correct approach

 

The problem with (1) approach is that it doesn’t address the underlying issue – search_sql_ldap is throwing an exception.  The correct approach is to figure out why.  Do you have any error output or lines in the error log associated with this failure?

 

 

 

 

 

Adam Field SHERPA services analyst developer

 

 

Thanks both!

 

It looks like the issue here is a data issue. A function in Authorid.pm has had some code added to it which checks against a database table for users which are no longer at the institution, however it doesn’t seem to be able to cope with a user that isn’t present in that table. The function is:

 

sub get_value_label

{

                my( $self, $session, $value ) = @_;

 

                my $user = EPrints::DataObj::User->new( $session, $value );

               

                #Checks the normal process and returns the user if found.

                if( defined $user )

                {

                                return $session->make_text( EPrints::Utils::make_name_string( $self->_get_name( $session, $user ) ) );

                }

               

                #If not returned with normal user checks value is a valid number and trys to pull the user from the ldap_user table instead

                if ($value =~ /^[+-]?\d+$/ )

                { 

                                if (scalar @{$session->get_database->search_sql_ldap($value)}){ << THIS IS THE LINE THAT’S GIVING ME GRIEF!

                                    my @check = @{$session->get_database->search_sql_ldap($value)};

 

                                    if(defined($check[0][0]) && defined($check[0][1]))

                                    {

                                                my $string_build = $check[0][0] . ", " . $check[0][1];

                                                return $session->make_text( $string_build );

                                    }

                                }

                }             

               

                #Otherwise just simply output the value

                return $session->make_text( $value );

                #return $session->make_text( "me" );

}

 

…and I’ve marked the problematic line of code. When it encounters an empty string instead of a scalar, the view generator goes…

 

¯\_(ツ)_/¯

 

…and falls over. Giving us no generated views. And a 500 error. Which is nice.

 

So, I think the answer is to handle that empty string and let the function carry on to the fallback of returning the value, however my knowledge of perl is less than functional at best and I really don’t want to do any more irrevocable damage. Any thoughts would be welcome!

 

Andrew

 

 

> bin/generate_views ARCHIVEID --view viewid --verbose

 

(You can do ‘--verbose --verbose’ if you really need to!).

 

Depending on where your issue lies, you might want to use one of these options too:

--generate menus

--generate lists

 

Which will be a bit quicker than a full run.

 

Cheers,

John

 

 

Hello all!

 

So, back to that old chestnut of errors throwing in our EPrints installation (yay!) I’ve had to do some tweaks to make it read our LDAP table. Now I’m getting errors on the creator browse generation! I think I’ve figured out where the problems are occurring however I don’t know if it’s a code issue or a data issue. Is there a way of running the view generator from the command line with –verbose so that I can see what it’s trying to do and figure out where the error is occurring?

 

Andrew

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.