Owen Leonard wrote:
> The advantage of the accesskey method is of course that it's not
> javascript-dependent. The disadvantage is that different browsers
> handle accesskeys differently, a combination of keys is usually
> required (Alt+ or Ctrl+Alt+), and not all keys or key combinations
> will b
> > not all keys or key combinations
>> will be available (for instance, because of conflicts with built-in
>> browser shortcuts).
>
> Why would accesskeys conflict with built-in browser shortcuts?
I simply mean that we can't choose from the full array of possible
keys because some keys will alrea
Our MS AD LDAP schema provides samaccountname but not UID, so we map
.
Test 1A: someuser + password
1
1
1
%...@example.com
Result 1A: Can't call method "exists" on an undefined value at
/usr/share/koha/lib/C4/Auth_with_ldap.pm line 168, line 253.
Test 1B: someu...@exam
Developers,
Currently, my catalogers use OCLC Connexion to search for and update
bibliographic records. Upon completion of a record, they simply press F5, and
the record is imported into our existing ILS. The window that pops up gives
them the current status of the export, and a report back
I don't see an exists() call on line 168 of Auth_with_ldap.pm. What
version of Koha are you using again?
The nearest call is in ldap_entry_w_hash(). Actually that's the only
call I could find in the current version of the file.
ldap_entry_2_hash() is called after authentication though, so that s
Michael, just to make sure I just finished another fresh dev install
(3.00.02.012) from git on a fresh machine. Still have the exact same
problem. :-(
On Wed, Jul 15, 2009 at 10:04 AM, Michael Hafen wrote:
> I don't see an exists() call on line 168 of Auth_with_ldap.pm. What
> version of Koha a
Owen Leonard writes:
> Going forward, how should we choose the default keyboard shortcuts?
>
> Should we attempt to fall back on accesskeys? If no, should we expand
> the use of js-based keyboard shortcuts?
The ideal solution is to employ a simple keyboard shortcut map interface. Of
course ther
Galen Charlton writes:
> I think whatever we do, we shouldn't hard-code the specific key
> bindings or scatter the bindings across multiple templates.
Right, simple is good. I wondered about the F12 myself!
___
Koha-devel mailing list
koha-de...@
Yeah, I've been looking at the 3.1.x version of the file. The
auth_by_bind and principal_name features aren't in the 3.0.x branch
(yet). And you mention that you are using Active Directory, and I don't
know if Auth_with_ldap.pm will work with AD. It's a matter of AD
exposing a userPassword attri
I haven't been following this thread in detail, but MS Active Directory LDAP is
working with my instance of Koha 3.0.1, which is running on Debian Lenny.
My configuration is as follows:
1
[server IP]
[Active Directory Distinguished Name of Domain]
[Active Directory Distinguished Name of AT a
Oops,
That should have read:
"[Active Directory Distinguished Name of *AD* admin user]"
Cheers,
Christopher Curry
Assistant Technical Librarian / Assistant IT Officer
American Philosophical Society
105 South Fifth Street
Philadelphia, PA 19106-3386
Tel. (215) 599-4299
ccu...@amphilsoc.org
Chris, yes in Koha 3.0.1 my test users could authenticate against AD
using , but Koha was not creating or updating their Koha
accounts despite and set to 1. In addition, our
I.T. dept will not provide me an AD Admin account; only an alternate
domain account for doing queries only. (userpassword
Dobrica Pavlinusic
writes:
> Idea is simple: instead of having single administrative user which can
> do LDAP compare to check password, we just bind as user who is trying
> to login.
Yes, this is the correct way to authenticate against an LDAP directory.
As you say, it requires no privileged ac
13 matches
Mail list logo
