scriptotek / almar Goto Github PK

View Code? Open in Web Editor NEW

6.0 6.0 1.0 303 KB

Script for editing or removing subject fields (648/650/651/655) in bibliographic records in Alma

License: GNU Affero General Public License v3.0

Python 100.00%

alma authority-control bibliographic-records marc21

almar's People

Contributors

Stargazers

Watchers

Forkers

mjlassila

almar's Issues

Håndtering av CZ-poster

Redigering av CZ-poster med det vanlige Alma GUI-et

Eksempel: 999919926696702201,

Vi kan i utg. pkt. redigere CZ-poster (CKB-poster) i Alma: Contributing to the Community Zone – Bibliographic Records.
Søk etter Is linked equals "Yes") i Network Zone for å finne poster lenket til CZ. Avgrenser vi til Authority Vocabulary: noubomn ser vi at det bare er et 6 poster som foreløpig kan skape problemer for lokar, men det kan jo bli flere i fremtiden.
Hvis man er logget inn i f.eks. UBO-instansen av Alma, funker det både å redigere poster i NZ og i CZ.
(... men det funker ikke å redigere dem med normaliseringsjobber. Disse feiler med feilmeldingen "Record is linked")

Redigering av CZ-poster med API-et

Med en API-nøkkel for UBO-instansen kan man kun redigere IZ-poster. Hvis man forsøker å redigere en post som er lenket til NZ eller CZ blir denne kopiert til IZ og lenkingen blir brutt (uten noen advarsel).
For å redigere en NZ-post fra API må man bruke en egen API-nøkkel for NZ.
Men hva med CZ-poster? Jeg spurte på https://developers.exlibrisgroup.com/discussions#!/forum/posts/list/322.page

Add new MARC subfields in order

We probably would like to add $x after $a, not after $0 and $2, like here:

almar --search 'alma.all_for_ui="999707921404702201"' --diffs interactive 'Strukturer' 'Tynnfilmer : Magnetiske egenskaper'
[…]
2017-09-18 16:04:34 INFO     SRU search: alma.all_for_ui="999707921404702201"
2017-09-18 16:04:34 INFO     1 catalog records found

999707921404702201: Ultrathin magnetic structures. An introduction to the electronic, magnetic and structural properties. 1. c1994
    650 #0 $a Thin films $x Magnetic properties
    650 #0 $a Metallic films $x Magnetic properties
    650 #0 $a Free electron theory of metals
    650 #0 $a Magnetic films
  > 650 #7 $a Strukturer $2 noubomn
    653 ## $a tynne $a magnetiske $a filmer $a strukturer
[?] Make a selection (or press Ctrl-C to abort):
 > X 650 $a Tynnfilmer $x Magnetiske egenskaper $2 noubomn $0 (NO-TrBIB)REAL022280
   o None of them (remove the field)

--- Original
+++ Modified
@@ -11,7 +11,7 @@
 650 #0 $a Metallic films $x Magnetic properties
 650 #0 $a Free electron theory of metals
 650 #0 $a Magnetic films
-650 #7 $a Strukturer $2 noubomn
+650 #7 $a Tynnfilmer $2 noubomn $0 (NO-TrBIB)REAL022280 $x Magnetiske egenskaper
 653 ## $a tynne $a magnetiske $a filmer $a strukturer
 700 1# $a Bland, A. $0 (NO-TrBIB)90983570
 700 1# $a Heinrich, B. $0 (NO-TrBIB)90983571
2017-09-18 16:04:45 INFO     Job complete

Improve handling of the Alma SRU search limit (10 000 records)

From https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/Alma_Online_Help_(English)/Integrations_with_External_Systems/030Resource_Management/190SRU%2F%2F%2F%2FSRW_Search

When doing an external search using SRU (Search/Retrieve via URL) and retrieving 10,000 or more records, Alma responds with an error message when it retrieves the next bulk of records exceeding the 10,000 limit. SRU integration is intended for integrating Alma search with other automated systems for the purposes of interlibrary loan, copy catalog, or selection. Using SRU integration for other workflows, such as performing bulk exports of records, is not supported.

Currently, Lokar will crash with an SruException after having retrieved 10,000 records.. This is rather silly, it would be better to bail out immediately once we see that the result list contains more than 10,000 records.

Oppdatere $0

Hvis vi fletter et begrep inn i et eksisterende begrep, må vi passe på at $0 blir oppdatert for de postene som har $0.

Oppdatering av en post fører til at `created_by` og `created_date` endres

Det er ikke kritisk, men virker som en bug. Meldt på https://developers.exlibrisgroup.com/discussions#!/forum/posts/list/323.page

<   <created_by>import</created_by>
<   <created_date>2015-11-02Z</created_date>
<   <last_modified_by>System</last_modified_by>
<   <last_modified_date>2015-12-06Z</last_modified_date>

---
>   <created_by>exl_api</created_by>
>   <created_date>2016-05-06Z</created_date>
>   <last_modified_by>Update MMS Record API</last_modified_by>
>   <last_modified_date>2016-05-06Z</last_modified_date>
23c23

Mer komplekse former for søk (og erstatt)

Søk vi allerede støtter:

650{$a=Fysikk} OR 650{$x=Fysikk}
650{$a=Fysikk}{$x=Historie}

Søk det kunne vært interessant å støtte:

(1) Fra streng til sammensatt begrep

650{a=Fysikk} AND 655{a=Historie}

for å erstatte 650 Fysikk 655 Historie med 650 Fysikkhistorie.

Jeg lurer på om vi kan bruke en slik syntaks for mer avanserte søk.. for å forenkle kan vi begrense oss til kun AND eller OR i ett søk, og kanskje bare to eller tre ledd.

Hva trenger vi? OBS: Alma-SRU støtter ikke NOT

Testing

✓ Test 1: Enkel test

Eks.: "Algeoppblomstring" → "Algeoppblomstringer"

$ python lokar.py "Algeoppblomstring" "Algeoppblomstringer"

[2016-05-06 15:03:40 INFO] ============================ Starter jobb ============================
[2016-05-06 15:03:40 INFO] [ Miljø: nz_sandbox ] [ Vokabular: noubomn ] [ Bruker: meg] [ Tørrkjøring? NEI ]
[2016-05-06 15:03:40 INFO] Termen "Algeoppblomstring" ble autorisert med ID 012754
[2016-05-06 15:03:40 INFO] Erstatter "Algeoppblomstring" med "Algeoppblomstringer" i $a og $x i 650-felt som har $2 noubomn
[2016-05-06 15:03:44 INFO] [  1/ 23] 999823606304702201
[2016-05-06 15:03:46 INFO] [  2/ 23] 999011849184702201
[2016-05-06 15:03:48 INFO] [  3/ 23] 990416769984702201
[2016-05-06 15:03:51 INFO] [  4/ 23] 998030224684702201
[2016-05-06 15:03:53 INFO] [  5/ 23] 999101333524702201
[2016-05-06 15:03:55 INFO] [  6/ 23] 999523421624702201
[2016-05-06 15:03:58 INFO] [  7/ 23] 990408050694702201
[2016-05-06 15:03:00 INFO] [  8/ 23] 990318751144702201
[2016-05-06 15:03:02 INFO] [  9/ 23] 990122947644702201
[2016-05-06 15:03:05 INFO] [ 10/ 23] 999203769164702201
[2016-05-06 15:03:07 INFO] [ 11/ 23] 998411258724702201
[2016-05-06 15:03:10 INFO] [ 12/ 23] 991501360304702201
[2016-05-06 15:03:12 INFO] [ 13/ 23] 999002459724702201
[2016-05-06 15:03:14 INFO] [ 14/ 23] 999008014764702201
[2016-05-06 15:03:17 INFO] [ 15/ 23] 999201587904702201
[2016-05-06 15:03:19 INFO] [ 16/ 23] 990200201714702201
[2016-05-06 15:03:21 INFO] [ 17/ 23] 997540281274702201
[2016-05-06 15:03:23 INFO] [ 18/ 23] 999411853624702201
[2016-05-06 15:03:25 INFO] [ 19/ 23] 998901137184702201
[2016-05-06 15:03:27 INFO] [ 20/ 23] 998030845954702201
[2016-05-06 15:03:29 INFO] [ 21/ 23] 999515142704702201
[2016-05-06 15:03:31 INFO] [ 22/ 23] 999004375454702201
[2016-05-06 15:03:33 INFO] [ 23/ 23] 999222161344702201
[2016-05-06 15:03:35 INFO] ============================ Jobb ferdig =============================

for f in $(ls | cut -d'.' -f1 | uniq); do
  echo "$f:"
  echo '```diff'
  diff "$f.before.xml" "$f.after.xml" | tail -n +19;
  echo '```'
done

990122947644702201:

161c161
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

990200201714702201:

85c85
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

990318751144702201:

96c96
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

990408050694702201:

91c91
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

990416769984702201:

86c86
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

991501360304702201:

87c87
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

997540281274702201:

56c56
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

998030224684702201:

82c82
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

998030845954702201:

97c97
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

998411258724702201:

87c87
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

998901137184702201:

91c91
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999002459724702201:

114c114
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999004375454702201:

117c117
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999008014764702201:

107c107
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999011849184702201:

80c80
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999101333524702201:

86c86
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999201587904702201:

136c136
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999203769164702201:

110c110
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999222161344702201:

102c102
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999411853624702201:

103c103
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999515142704702201:

118c118
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999523421624702201:

122c122
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

999823606304702201:

97c97
<       <subfield code="a">Algeoppblomstring</subfield>

---
>       <subfield code="a">Algeoppblomstringer</subfield>

/usr/bin/env: bad interpreter

Got this error on a machine now:

-bash: /usr/bin/almar: "/usr/bin/env: bad interpreter: No such file or directory

The issue is incorrect escaping of build_scripts.executable in setup.py. It has been fixed in recent versions of setuptools, so pip install -U setuptools followed by a reinstall almar will fix the issue.

Ref. pypa/setuptools#188