[Kobv-opus-tester] zusätzliches Suchfeld

Sascha Szott szott at zib.de
Don Sep 27 17:29:18 MEST 2012


On 27.09.2012 16:52, Annegret Baade-Kelishani wrote:
> Ich glaube, Sie meinen die Datei solr.xslt.
Ja genau, die meine ich.

>> Wenn ich die Email hier eintrage,
>>   <xsl:for-each select="/Opus/Opus_Document/PersonAuthor">
>>                     <xsl:element name="field">
>>                         <xsl:attribute name="name">author</xsl:attribute>
>>                         <xsl:value-of select="@FirstName" />
>>                         <xsl:text> </xsl:text>
>>                         <xsl:value-of select="@LastName" />
>>                         <xsl:text> </xsl:text>
>>                         <xsl:value-of select="@Email" />
>>                         <xsl:if test="position()!=last()">
>>                         <xsl:text> ; </xsl:text>
>>                         </xsl:if>
>>                       </xsl:element>
>>                 </xsl:for-each>
>
> wird sie auch gefunden, das klappt gut. Nachteil ist allerdings, dass
> sie dann in der Listenanzeige in der Frontdoor auch angezeigt wird
das liegt daran, dass das Indexfeld 'author' sowohl für die Suche als 
auch die Anzeige verwendet wird. Sie könnten aber folgendes Vorgehen 
wählen: statt die E-Mail-Adresse mit in das XML-Element <field 
name="author"> zu schreiben, erzeugen Sie ein neues XML-Element <field 
name="text">. In dieses Feld (kann auch mehrfach vorkommen) können Sie 
nun alle Inhalte schreiben, die in der einfachen Suche durchsucht werden 
sollen. Die Feldinhalte werden aber an keiner Stelle innerhalb der 
Webapplikation ausgegeben.

Beispiel:

<xsl:for-each select="/Opus/Opus_Document/PersonAuthor">
   <xsl:element name="field">
     <xsl:attribute name="name">text</xsl:attribute>
     <xsl:value-of select="@Email" />
   </xsl:element>
</xsl:for-each>

Nach dieser Anpassung *müssen Sie eine Reindexierung durchführen*. Dazu 
rufen Sie im Verzeichnis $BASEDIR/opus4/scripts das PHP-Skript 
SolrIndexBuilder.php auf. Je nach Dokument- und Volltextanzahl kann das 
eine Weile dauern…

Noch die Warnung: Sie müssen in Zukunft bei jedem OPUS4-Update die Datei 
solr.xslt händisch pflegen, da das Updateskript nicht annimmt, dass Sie 
die Datei angepasst haben.

>> Wer ruft denn in ihrem Szenario den
>> Export auf? Der Client (Browser des Benutzers) per AJAX oder das CMS,
>> das die Publikationslisten im Hintergrund bereits erzeugt und dann
>> serverseitig nur noch in die Seite "einhängt"? Im zweiten Fall könnte
>> man durchaus die Suche nach E-Mail-Adressen als privilegierte Funktion
>> betrachten, die nur ausgewählte Benutzer durchführen dürfen. Dann würde
>> man dem CMS-Prozess mit den erforderlichen Rechten für diese Operation
>> ausstatten.
> Zur Zeit das CMS. Von daher wäre es für mich natürlich auf jeden Fall
> schon mal ein Fortschritt, wenn ich wüsste, wie man solch eine
> privilegierte Funktion einrichten würde. Flexibler wäre man aber, wenn
> auch der Weg über AJAX möglich wäre, man weiß ja nie, welche Anforderung
> als nächstes kommt ...
Sie legen eine neue User-Rolle, z.B. cms, an und geben dieser das Recht 
das Modul 'export' aufrufen zu können. Anschließend weisen Sie der Rolle 
eine IP-Adresse (des Rechners, auf dem das CMS läuft bzw. der Job, der 
die Ausgabe für das CMS generiert) zu. Der Rolle guest entziehen sie nun 
den Zugriff auf das Modul. Nun kann der Export nicht mehr von jedem 
beliebigen Benutzer aufgerufen werden.

Dieses Vorgehen verhindert aber nicht, dass jemand über die einfache 
Suche nach einer Mailadresse sucht. Sie können also bislang nicht 
einstellen, dass nur bestimmte User-Rollen auf bestimmte Suchfelder 
zugreifen können.

AJAX ist auch jetzt schon möglich. Die Frage ist nur, wie performant das 
am Ende ist. Die Erzeugung eines XML-Exports kann je nach Größe einige 
Sekunden dauern. In jedem Fall müssten Sie aber bei dieser Variante 
wieder allen den Zugriff auf das Modul 'export' gestatten.

Beste Grüße,
Sascha Szott

-- 
Sascha Szott :: KOBV/ZIB :: <szott at zib.de> :: +49 30 84185-457