Search and logical indices
Hi! To ease up the searches for our users I set up several additional indices that should allow to search some "strange" Marc-fields in an easy way. Now, I have e.g. an index called CID, that uses the logical field "[CID] contributing institute ID", set up as follows: Field Code: CID Name (en) : [CID] contributing institute ID Marc tags : 980__a 9201_0 bibindex, have cup of coffee or tea, Tada! Now I can indeed select "[CID] contributing institute ID" from the search box, give one of our funny IDs like "I:(DE-Juel1)ZB-20090406" as search term an. Heureka! This tells me that the index creation and indexing itself proceeded and I didn't do something wrong, right? Now, I thought I should be able to use this index also for searches within the search box just like a marc field, e.g.: CID:"I:(DE-Juel1)ZB-20090406" IMHO this should accomplish the same thing. However, it seems that there's some conversion going on... &verbose=9 tells me that invenio is searching in the field cid which does not exist. (?) * Could it be that the name of the logical fields have to be in lower case? At least the above doesn't give any results. However, if I change the field code to "cid" it seems to work fine. If this is intended I'd have a line for the bibindex-admin-guide on the wish list ;) * Just for my understanding: if I'm searching like the above I'm effectively searching the logical field, not the index CID, right? Ie. an index could be made up of many logical fields. However, as far as I understand it, I can not search it. Just for my understanding, I can live with defined fields. I'm just wondering what the "index" as such is doing. -- Kind regards, Alexander Wagner Subject Specialist Central Library 52425 Juelich mail : a.wag...@fz-juelich.de phone: +49 2461 61-1586 Fax : +49 2461 61-6103 www.fz-juelich.de/zb/DE/zb-fi Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt Kennen Sie schon unsere app? http://www.fz-juelich.de/app
Re: Issue with websubmit_engine (when mbpages>1)
Hello Sam, We constantly use submission forms with multiple pages, and i can assure you that apart from this problem (and some other issues with custom javascript elements that don't get initialized with the previous value -something that is more or less an expected behavior of my poor programming skills) moving back and forth has been working flawlessly for us for several years! So please do ticketize it and try to find a solution... :) Coming to think of it, a quick workaround might require that the submission form writes the values of ALL elements, even empty ones... (although I'm confident that you'll come up with a more elegant solution!) Best regards, Theodoros
Re: Issue with websubmit_engine (when mbpages>1)
Dear Theodoros,
In data lunedì 22 ottobre 2012 18:15:47, Theodoros Theodoropoulos ha scritto:
> When submitting using the web forms and only if a document has more than
> 1 page, when you navigate from one page to another:
>
> If an element already has a value[*] in pg1 and you edit it, then go to
> pg2, everything is OK :)
> If an element already has a value[*] in pg1 and you DELETE THE VALUE
> COMPLETELY, then go to pg2, and then BACK to pg1, you see the old value!
> This means that the FILE in the disk that corresponds to this element is
> NOT updated IF the new value is "" (although the system checks of the
> page see the 'new', empty value).
>
> This results in users not being able to 'empty' old values when moving
> from one page to another. One can only change them into something else!
>
> I can verify that it appears in a snapshot of master branch taken from
> git 3 weeks ago, but i believe it appears in earlier/later releases. Can
> you verify it? If yes, I think it's a bit important and needs fixing...
>
> [*] either by continuing a previously-incomplete submission, or by
> entering a value, going to another page and then back
Indeed WebSubmit is not enough robust in supporting moving back and forth
submission form. However your report is well detailed to allow for a possible
solution.
I suspect we should introduce some support for the above somewhere in
websubmit_engine.py in the interface function near:
[...]
# we parse all the form variables
for key, formfields in form.items():
filename = key.replace("[]", "")
file_to_open = os.path.join(curdir, filename)
try:
assert(file_to_open == os.path.abspath(file_to_open))
except AssertionError:
register_exception(req=req, prefix='curdir="%s", filename="%s"' %
(curdir, filename))
return warning_page(_("Invalid parameters"), req, ln)
# Do not write reserved filenames to disk
if filename in CFG_RESERVED_SUBMISSION_FILENAMES:
# Unless there is really an element with that name on this
# page or previous one (either visited, or declared to be
# visited), which means that admin authorized it.
if not ((str(curpage).isdigit() and \
filename in [submission_field[3] for submission_field in \
get_form_fields_on_submission_page(subname,
curpage)]) or \
(str(curpage).isdigit() and int(curpage) > 1 and \
filename in [submission_field[3] for submission_field in \
get_form_fields_on_submission_page(subname,
int(curpage) - 1)]) or \
(previous_page_from_disk.isdigit() and \
filename in [submission_field[3] for submission_field in
\
get_form_fields_on_submission_page(subname,
int(previous_page_from_disk))])):
# Still this will filter out reserved field names that
# might have been called by functions such as
# Create_Modify_Interface function in MBI step, or
# dynamic fields in response elements, but that is
# unlikely to be a problem.
continue
[...]
I'll ticketize it and we should be hopefully able to find a solution :-)
Cheers!
Sam
--
Samuele Kaplun
Invenio Developer **
