← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
11:24 | owen | paul: on our system we're going to hide the 'add to shelf' button from users who aren't logged in. Shall I make the same change to the default templates in rel_2_2? |
12:03 | paul | owen : yes, I think it's the best solution |
12:03 | owen | paul, do you have time for another question? |
12:04 | paul | a quick one, yes. |
12:04 | a complex one, no | |
12:04 | throw it anyway ;-) | |
12:04 | owen | I asked recently about modifying opac-user.pl to check whether the user was logged in or not. hdl said "you can test C4::Context->userenv and $userenv->{userid}" |
12:05 | Can you expand on that recommendation? | |
12:05 | paul | what kind of "expand" ? |
12:05 | hdl | I can : |
12:05 | owen | Hi hdl |
12:06 | paul | it was a quick question :-D |
12:06 | hdl | If C4::Context->userenv is not null and C4::Context->userenv->{userid} ne "" |
12:07 | then a user is logged in. (Needs to be tested for privileged user on db) | |
12:08 | That should be enough to test if user is logged in. | |
12:08 | BEWARE : this verification works provided that you do the test *AFTER* get_template_and_user | |
12:09 | owen | what I'd like to do is display one thing on opac-user.pl if the user is logged in, and another if they are not |
12:09 | hdl | then |
12:09 | you can | |
12:10 | After a gettemplateanduser call | |
12:12 | if (C4::Context->userenv && C4::Context->userenv->{'userid'} ne ""){$template->param(myparam=>C4::Context->userenv->{'userid'});}else{} | |
12:13 | A code as such would answer your demand. | |
12:13 | kados | owen: you should be able to try this on 101 |
12:14 | owen | yeah, that's my plan |
12:14 | kados | cool |
12:15 | hdl | OR this one :"if (C4::Context->userenv && C4::Context->userenv->{'userid'} ne ""){$template->param(myparam=>C4::Context->userenv->{'cardnumber'});}else{}" |
12:15 | change userid into cardnumber | |
12:15 | dewey | hdl: that doesn't look right |
12:16 | hdl | what's up dewey |
12:16 | owen | dewey is a Perl expert now? |
12:19 | hdl | kados : can you tell me more about your search.pl and especially about limit type to ... ? |
12:19 | What is it related to... | |
12:20 | in record.abs | |
12:20 | in your database ? | |
12:20 | Is it itemtype ? | |
12:20 | Where (and why) is it hardcoded. | |
12:20 | ? | |
12:28 | owen | hdl: that IF seems to evaluate as false whether or not the user is logged in |
12:39 | hdl | owen : can you send me a version of the code henridamien at koha hyphen fr dot org |
12:39 | ? | |
12:40 | did you try with cardnumber ? | |
12:40 | owen | Ah, cardnumber worked |
12:41 | Thanks, I'll see what I can do with this. | |
12:48 | kados | hdl: the type and subtype limits are related to MARC21 fixed fields |
12:48 | hdl: it's perhaps the most complex part of the search API | |
16:19 | owen | Hi cm |
16:22 | cm | Hi. Did you get the email i just sent you? |
16:24 | owen | Yes |
16:24 | kados told me that updatedatabase was out-of-date for dev_week | |
16:25 | cm | i thought it might be but was hoping it wasn't. ;) |
16:25 | good thing for backups! | |
16:25 | owen | Yeah, I'm not sure what the solution there is. |
16:26 | I think a lot of what's in dev_week isn't expected to be used in an automated installation process | |
16:27 | cm | yeah. I noticed in rel_3_0 that some of the new fields have moved to biblioitems (IIRC) but in dev_week they're in their own table, at least in the changes created by updatedatabase. Where are they in your database? |
16:29 | owen | I'm not following 3.0 very closely at the moment so I'm not sure what you're referring to |
16:30 | cm | hmm...I think I was looking at the different versions of updatedatabase to compare what they do. |
16:35 | kados | cm: dev_week's updatedatabase is not safe to use |
16:35 | cm | for example, the 3.0 script puts the ccode field in biblioitems, but in the dev_week version, it looks like there's a whole table dedicated to categorycode, which I'm assuming is the same thing. It didn't create a ccode field in biblioitems. |
16:36 | kados: yep, I found that out. It broke issuing. | |
16:36 | I can fix that easily enough, though. | |
16:37 | kados | cm: are you going Winebego -> rel_2_2 -> dev_week? |
16:38 | cm | rel_2_2 from cvs or 2.2.5, whichever the last release prior to yesterday's was? |
16:38 | kados | the release is just a snapshot of cvs on a particular day |
16:39 | cm | I was going from Winnebago -> 2.2.5 -> dev_week |
16:39 | kados | 2.2.5 or rel_2_2 ? |
16:39 | cm | 2.2.5 |
16:39 | kados | hmmm |
16:39 | cm | I think I ran the updatedatabase from rel_2_2 when I installed, though. |
16:39 | kados | ahh, yea, that's what I was after |
16:39 | cm | ok. :) |
16:40 | kados | so at some point your have a rel_2_2 database |
16:40 | that's good | |
16:40 | cm | yeah. |
16:40 | it's missing some fields, though, isn't it? | |
16:40 | kados | yep |
16:40 | lemme update the wiki | |
16:40 | cm | is there an sql script to add them? |
16:40 | kados | I'm checking |
16:40 | cm | cool. |
16:43 | kados | cm: http://wiki.koha.org/doku.php?[…]_the_sql_database |
16:44 | cm: I'll update that section | |
16:44 | cm | Okay, excellent! |
16:51 | kados | cm: the problem is that the upgrade process from rel_2_2 is different depending on your situation |
16:51 | like in your case, everything is already in utf-8, so you can ignore all of that stuff | |
16:52 | cm | ok. |
16:52 | kados | cm: ok, that link is up to date |
16:52 | cm: not much changed | |
16:52 | cm | cool beans. Thanks very much! |
16:53 | kados | np, let me know if you have questions |
16:55 | cm | you know i will. :D looks pretty straightforward. Think I'll save it for tomorrow morning. Have a good night. |
16:55 | kados | you too |
03:11 | btoumi | hi all |
03:15 | toins | morning all |
← Previous day | Today | Next day → | Search | Index