Am 14.01.2011 15:28, schrieb Samuele Kaplun:

Hello Samuele!

Thank you for your very quick answer!

(project-cdsware-users mailing list added in CC as this
topic might be of interest to others as well :-) ).

Sorry, I missed it in the initial posting. Not intentionally
though.

I'm trying to find my way through the new embargo
functions you introduced some time ago. For this I use
[...]
However, if I try to access the document today it is
locked. What am I doing wrong here?

Great job for using ^M character!

I admit I was about to suggest to allow also for another
character in the role definition for easier handling. ;)

The usage is almost correct but for the missing
"firerole:" prefix in front of it. You should in fact
specify the kind of restriction which can be "email:",
"group:", "role:", "firerole:" or "status:". If you don't
specify the "firerole:" prefix, than the "status:" prefix
will be used to retain back-ward compatibility with the
past. (where only traditional WebAccess based
authorizations where possible using the 'viewrestrdoc'
action with the 'status' parameter).

If I may, I would suggest to add this to the --help of
bibdocfile. Probably, also with some example. As a newbe
you'll most likely stumble upon such things.

Still, I seem to do something wrong. What I understand from
your mail is that I should use something like

   $ ./bibdocfile -r 106 --set-restriction='firerole:
   ALLOW FROM "2011-01-01"
   ALLOW ALL
   '

This should result in the file available from 1st of January
this year by the first rule, so this test passes and the
second line is executed giving access before the final
implicit DENY ALL locks the file. Now, issuing the above
triggers a bibupload process which proceeds.

Then I check what I won:

   $ ./bibdocfile -r 106 --get-info

This results in something like:

[...]
   106:95:::doctype=Main
   106:95:::status=firerole: ALLOW FROM "2011-01-01"
   ALLOW ALL

   106:95:::basedir=/opt/invenio/var/data/files/g0/95
   106:95:::creation date=2011-01-14 15:12:58
[...]

If I get it correctly, in the second line "status=" should
have changed to "firerole=", right? Additionally, I still
have the problem, that the file as such is locked, though
the clock is clearly beyond 2011-01-01. Thus if I try to
download the file I'm redirected to the login page and once
I have become John Doe wiht out any rights it tells me this
file is locked.

And while I am at it: is there a way to apply an embargo
from the web frontend? The FFT-field is not part of the
MARC. The above cli interface is fine with me but our
collegue who will have to set those embargos on a regular
basis would feel more comfortable there.

Thank you in advance for your reply!

Not yet out of the box. What you can do is to create a
submission interface in WebSubmit and plug somewhere an
ad-hoc WebSubmit function that would iterate over all the
BibDocFiles attached to a record and set the restriction
to a given rule (that, since it specify a given date, must
be computed on the fly).

That sounds like a solution indeed.

I attach an example of such function (note that such
function might be available in the next release
candidates, so if you decide to use and modify it, please
give it another name to avoid having your version being
overwritten by a make install).

Thank you! At present I can wait very well for the next rc
with this. I'm mainly testing some backend stuff here so I'm
comfortable with the CLI.

I wonder, however, if it wouldn't make sense to rethink fft
subfield. It seems sensible that firerole definitions for a
given file are accessible from the MARC editor and thus to
store them in some MARC field for easy handling. Also for
showing the embargo time on the details page and easy
transport of the records between two systems seem to hint at
this. What do you think?

--

Kind regards,

Alexander Wagner
Subject Specialist
Central Library
52425 Juelich

mail : [email protected]
phone: +49 2461 61-1586
Fax  : +49 2461 61-6103
http://www.fz-juelich.de/zb/mitarbeiter/fachinformation#wagner


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Reply via email to