Am 17.01.2011 17:29, schrieb Samuele Kaplun:
Hello Samuele!
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. ;)
That is a good one, although it would make the parsing of
firerole rules a bit more complex (since you would need to
properly understand that additional character when it
happens e.g. inside group-name-based authorizations)
Acutally, the main problem is IMHO to find an unproblematic
character(-sequence). The librarians would probably vote for
something like " ; " but that could come up within the rule
easily. Otherwise, if a clean char(sequence) could be found
I think one could adjust your split-call for allowing
something different than \n. I didn't suggest the usage of
another char simply cause I've not found a suitable one yet.
:S
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?
Nope. Status is just a generic attribute of a bibdoc. So when the status
is "firerole: foo", then the status is interpreted as firerole rule. If
the status was "DELETED" then the file would have been considered as
deleted...
Ah, ic. I missunderstood your comment about "status".
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.
That is strange. I should investigate this and come back
to you ASAP.
Thanks. I actually tried this yesterday again with a
completely fresh rc1 install containing only the demo site
and was not able to get it working.
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?
There has been indeed some internal talking on putting
both record-level and document-level restriction in the
MARC although it will take a bit before it will made into
Invenio in a stable way.
Probably it should go along with holdings information for
"classical" books to give a common framework. The nice thing
to have it in Marc is of course easy transition from other
systems.
Besides the conceptional issue... Originally, I come from
a PICA environemnt and I admit that I always liked of PICA
that you just get one simple MLE field (I'd just liked to
have vi keybindings ;) for record editing and it contains
bibliogrpahic level, local information and holdings. In Marc
speach this would at least put bibliographic and holdings
into one display. From a cataloguers point of view, though
it has some learning curve, PICAs approach is IMHO the most
convenient way to handle things. (It's so much faster to
just key in 245 __ $abla then jumping through entry lines
and mouse clicking here and there to add fields.) But surely
this is no trivial thing done in a lazy afternoon. But
probably worth considering.
--
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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
