Document restriction

[Maddog]

Hi,
I am unsuccessfully trying to set document restriction. There should be some restricted picture in demo site, but whem I try to load demo records, something goes wrong and the restricted picture won't load, so I don't know how is the final stage suppose to look.
I am trying to insert something like:

<datafield tag="FFT" ind1=" " ind2=" "><subfield code="a">http://10.0.2.37/subtools.zip</subfield><subfield code="r">program</subfield></datafield>

in my MARCXML file and upload it. Then i set viewrestrdoc action to some role with status="program". I hope that is supposed to do the trick, but this doc is still available for all folks to download.
What is the "thing" that tag certain document to be restricted?
Thanks for help...

[skaplun]

Hi,

your procedure looks fully correct to me.

What actually is shown if you do:

$ sudo -u apache /opt/cds-invenio/bin/bibdocfile --get-info --recid THE-RECID

there should be a line showing the status, confirming the value was properly set to "program".

Also what is the definition of the role you attached to the authorization? Could it be that it has a too broad FireRole definition such as allow any? (just trying to exclude the obvious issues...)

Cheers,

Samuele

[Maddog]

There is what bibdocfile tells me:

1::::total bibdocs attached=1
1::::total size latest version=19.3 KB
1::::total size all files=19.3 KB
1:1:::docname=subtools
1:1:::doctype=Main
1:1:::status=
1:1:::basedir=/opt/cds-invenio/var/data/files/g0/1
1:1:::creation date=2010-09-01 09:46:59
1:1:::modification date=2010-09-01 09:46:59
1:1:::total file attached=1
1:1:::total size latest version=19.3 KB
1:1:::total size all files=19.3 KB
1:1:1:.zip:fullpath=/opt/cds-invenio/var/data/files/g0/1/subtools.zip;1
1:1:1:.zip:fullname=subtools.zip
1:1:1:.zip:name=subtools
1:1:1:.zip:status=
1:1:1:.zip:checksum=c3f549ac2c1e24a6ef0b8902bb64c8a6
1:1:1:.zip:size=19.3 KB
1:1:1:.zip:creation time=2010-09-01 09:46:59
1:1:1:.zip:modification time=2010-09-01 09:46:59
1:1:1:.zip:encoding=None
1:1:1:.zip:url=http://default-invenio.ntkcz.cz/record/1/files/subtools.zip
1:1:1:.zip:description=None
1:1:1:.zip:comment=None

the status line(s) shouldn't be empty right?

[Maddog]

Replying to skaplun:

There is what bibdocfile tells me:

1::::total bibdocs attached=1
1::::total size latest version=19.3 KB
1::::total size all files=19.3 KB
1:1:::docname=subtools
1:1:::doctype=Main
1:1:::status=
1:1:::basedir=/opt/cds-invenio/var/data/files/g0/1
1:1:::creation date=2010-09-01 09:46:59
1:1:::modification date=2010-09-01 09:46:59
1:1:::total file attached=1
1:1:::total size latest version=19.3 KB
1:1:::total size all files=19.3 KB
1:1:1:.zip:fullpath=/opt/cds-invenio/var/data/files/g0/1/subtools.zip;1
1:1:1:.zip:fullname=subtools.zip
1:1:1:.zip:name=subtools
1:1:1:.zip:status=
1:1:1:.zip:checksum=c3f549ac2c1e24a6ef0b8902bb64c8a6
1:1:1:.zip:size=19.3 KB
1:1:1:.zip:creation time=2010-09-01 09:46:59
1:1:1:.zip:modification time=2010-09-01 09:46:59
1:1:1:.zip:encoding=None
1:1:1:.zip:url=http://default-invenio.ntkcz.cz/record/1/files/subtools.zip
1:1:1:.zip:description=None
1:1:1:.zip:comment=None

the status line(s) shouldn't be empty right?

[skaplun]

Exactly...

Somehow upon the BibUpload FFT insertion the restriction was not taken into account.

What kind of bibupload mode have you used to insert your fulltext? --insert/--correct/--replace/--append?

Could you try again with another record and this time using bibupload with the option -v9 so that you can then look at the very verbose logs and see what went wrong?

[Maddog]

verbous upload log

[Maddog]

Replying to skaplun:
Ok,
I've attached fully verbous upload log. Hope it will reveal something...

[skaplun]

BibUpload patch to fix FFT handling when using -i -r and restrictions

[skaplun]

From the log I see you were using bibupload -i -r and indeed in bibupload code the restriction was not correctly handled in this situation.

I have attached a patch that you can apply with:

$ cd /opt/cds-invenio/lib/python/invenio
$ sudo -u apache cp bibupload.py bibupload.py-20100901 # to have a backup
$ sudo -u apache patch --dry-run -p4 < /tmp/bibupload.patch 
$ # if nothing bad happens
$ sudo -u apache patch -p4 < /tmp/bibupload.patch

I can not test the patch on a local installation, so can not confirm it already fully fixes your issue.

[Maddog]

Replying to skaplun:
Hooray, it works! Thanks a lot. That patch didn't work for some reason, so i had to rape the code manually. Well, thanks again and have a nice rest of the day.

Tomas

[Maddog]

Replying to skaplun:

One more thing. Is there some way how to set "status" to files obtained by WebSubmit? So no FFT, just 8564_ tag. Specifying $$r subfield doesn't seem to work here...