Ponderings on locations
Hi! While migrating our catalogue to Koha I get quite confused with the location handling. Location for me is "the place where I have to go to fetch the item". So an item could be in the general collection `main reading room`, but I may have a special area there like an exhibition or a new items shelf. And it can be at it's usual location or at some temporary place. AFAIS Koha items have internally a `location` and a `permanent_location`. (In my still current world they'd be named `temporary location` (876__l) and `location` (aka `852__a`), respectively, so slightly the other way round.) Now, in item cataloguing the location I get exposed to the editor seems to be a mixture of `permanent_location` and `location`, in the sense that the editor always sets both. Using mappings for `UpdateItemLocationOnCheckin` however, some values are magic. If `CART` and `PROC` get mapped they only change the `location`, while all others change both. (I do understand that the magic value is used by some cron-job.) However, I wonder if the procedures were not more flexible and easier to understand if "any mapped location" juggles the `location` and leaves the `permanent_location`, while I do get both values in the item editor and the actual place where an item is is defined as `permanet_location` if there is no `location` set. There is already `_PERM_` to access the permanent location in mappings, but with the current logic it's value is gone once a non-magical location enters the game. IMHO one could achieve the same functionality like now by just clearing `location` once an item is back at it's permanent location. (At least this is how our old system does it right now.) Example: - We order an item and set it's location to `On Order`. ORD is non-magical. - The item arrives, I check it in, `ORD: PROC` "moves" it to cataloguing. Cataloguing wants to change the permanent location. - After cataloguing it should go to the new items shelf. Check in, `PROC: NEW`. Everything fine in the OPAC display. - After a week or so on the new items shelf, check in, `NEW: _PERM_` moves it back to `on order`. To work around my trouble with the location, I played with a similar juggling for `UpdateNotForLoanStatusOnCheckin`. (Sidenote: it seems that I am required to use numbers for the values to juggle there, e.g. `-1: -3`, while the editor allows for text. If this is a bug I'd add one to bz.) This propagates as expected and from a display perspective it would also be ok. Unfortunately, the strict `not for loan` doesn't work well for us. We are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. If someone checks out an item that is in principle not for loan, I'd really like to check it out, just to know who has it ;) I did not yet find a way to soften `not for loan` to something like `2 days and immediately send a recall letter`. (Current procedure.) Additionally, we check in _all items_ from the CART all the time as we have a lot of patrons that just drop them into the box and they need to be returned to get the RFID into the proper state. (So in our case the cron wouldn't help.) BTW: what proved pretty flexible in our current system are what I called back then "special patrons". If I check out an item to those the item is not actually checked out, but they manipulate some Marc fields. We used them a lot to set the temporary locations to values like `repair`, `cataloguing`, `on display` or `library desk` (for items ready for the patron to fetch; Koha does this differently). Unlike checking in, where I have to rely on automatic propagation, checking out allows to select what I want to do by means of the cardnumber I get as a second parameter on the SIP-terminal. For configuration I used something like 788 _7 |2 P:(DE-HGF) |a {"j": "available", "l": "Cataloguing"} |i 8767_ which would set `876 7_ |javailable |lCataloguing`, ie the item is available, but in cataloguing. (Our patrons are currently just authority records, so I have full Marc at my disposal.) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
Forgive me if I add to your confusion a bit instead of clearing it up. There are actually three locations in Koha: Permanent location, current location, and shelving location. The first two only matter if you have more than one site; if you only have one site you can set them to the same value and effectively ignore them. These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location. I'll also mention that Koha can have pseudo patrons also, these can be one of many types. For example I have an Organizational type patron category called 'Library', and I may have a 'On Display', or 'Repair room' patron in that category. This doesn't help with automatically changing the Shelving Location though. There is also an 'after_circ_action' plugin hook. Perhaps there is, or you could have created, a Koha plugin to mangle the Shelving Location based on who an item is checked out to / returned from. On Tue, Mar 5, 2024 at 10:08 AM Wagner, Alexander via Koha-devel < koha-devel@lists.koha-community.org> wrote:
Hi!
While migrating our catalogue to Koha I get quite confused with the location handling. Location for me is "the place where I have to go to fetch the item". So an item could be in the general collection `main reading room`, but I may have a special area there like an exhibition or a new items shelf. And it can be at it's usual location or at some temporary place.
AFAIS Koha items have internally a `location` and a `permanent_location`. (In my still current world they'd be named `temporary location` (876__l) and `location` (aka `852__a`), respectively, so slightly the other way round.)
Now, in item cataloguing the location I get exposed to the editor seems to be a mixture of `permanent_location` and `location`, in the sense that the editor always sets both. Using mappings for `UpdateItemLocationOnCheckin` however, some values are magic. If `CART` and `PROC` get mapped they only change the `location`, while all others change both. (I do understand that the magic value is used by some cron-job.)
However, I wonder if the procedures were not more flexible and easier to understand if "any mapped location" juggles the `location` and leaves the `permanent_location`, while I do get both values in the item editor and the actual place where an item is is defined as `permanet_location` if there is no `location` set. There is already `_PERM_` to access the permanent location in mappings, but with the current logic it's value is gone once a non-magical location enters the game. IMHO one could achieve the same functionality like now by just clearing `location` once an item is back at it's permanent location. (At least this is how our old system does it right now.)
Example:
- We order an item and set it's location to `On Order`. ORD is non-magical. - The item arrives, I check it in, `ORD: PROC` "moves" it to cataloguing. Cataloguing wants to change the permanent location. - After cataloguing it should go to the new items shelf. Check in, `PROC: NEW`.
Everything fine in the OPAC display.
- After a week or so on the new items shelf, check in, `NEW: _PERM_` moves it back to `on order`.
To work around my trouble with the location, I played with a similar juggling for `UpdateNotForLoanStatusOnCheckin`. (Sidenote: it seems that I am required to use numbers for the values to juggle there, e.g. `-1: -3`, while the editor allows for text. If this is a bug I'd add one to bz.) This propagates as expected and from a display perspective it would also be ok.
Unfortunately, the strict `not for loan` doesn't work well for us. We are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. If someone checks out an item that is in principle not for loan, I'd really like to check it out, just to know who has it ;) I did not yet find a way to soften `not for loan` to something like `2 days and immediately send a recall letter`. (Current procedure.)
Additionally, we check in _all items_ from the CART all the time as we have a lot of patrons that just drop them into the box and they need to be returned to get the RFID into the proper state. (So in our case the cron wouldn't help.)
BTW: what proved pretty flexible in our current system are what I called back then "special patrons". If I check out an item to those the item is not actually checked out, but they manipulate some Marc fields. We used them a lot to set the temporary locations to values like `repair`, `cataloguing`, `on display` or `library desk` (for items ready for the patron to fetch; Koha does this differently). Unlike checking in, where I have to rely on automatic propagation, checking out allows to select what I want to do by means of the cardnumber I get as a second parameter on the SIP-terminal. For configuration I used something like
788 _7 |2 P:(DE-HGF) |a {"j": "available", "l": "Cataloguing"} |i 8767_
which would set `876 7_ |javailable |lCataloguing`, ie the item is available, but in cataloguing. (Our patrons are currently just authority records, so I have full Marc at my disposal.)
-- Kind regards,
Alexander Wagner
Deutsches Elektronen-Synchrotron DESY Library and Documentation
Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg
phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/
-- Michael Hafen Washington County School District Technology Department Systems Analyst
Hi!
Forgive me if I add to your confusion a bit instead of clearing it up. There are actually three locations in Koha: Permanent location, current location, and shelving location. The first two only matter if you have more than one site; if you only have one site you can set them to the same value and effectively ignore them.
Indeed I did not dive into "more than one site". I do have that also, but I understood that this is modelled on the `branch` concept.
These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location.
Yes. My question is mainly: how do I tell, also to patrons in the OPAC but also me if I explain the OPAC to a new patron, where to go for an item. E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location. (Currently, we add a temporary location like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.)
I'll also mention that Koha can have pseudo patrons also, these can be one of many types. For example I have an Organizational type patron category called 'Library', and I may have a 'On Display', or 'Repair room' patron in that category. This doesn't help with automatically changing the Shelving Location though.
I saw those and noticed that I can check out items. I was pondering those for items we temporarily remove from the collection. In our situation this doesn't help too much for items on some shelve though. We are open 24/7, so everyone with an access card can enter the library and take whatever is in the open shelves and even if _we_ checkout items we use the SIP-machine... IOW, even if _we_ think, that e.g. new items should be on display for a week or so you could take them. That's why I'd prefer to check items out even if this is not intended. IOW anything making things in the reading room unable to be checked out at all doesn't really work well for us.
There is also an 'after_circ_action' plugin hook. Perhaps there is, or you could have created, a Koha plugin to mangle the Shelving Location based on who an item is checked out to / returned from.
This sounds like an option to re-implement my special patrons. Thanks for the pointer. :) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
On Wed, Mar 6, 2024 at 1:11 AM Wagner, Alexander <alexander.wagner@desy.de> wrote:
Hi!
...
These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location.
Yes. My question is mainly: how do I tell, also to patrons in the OPAC but also me if I explain the OPAC to a new patron, where to go for an item. E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location. (Currently, we add a temporary location like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.)
I was recently looking at Shelving location actually, and this was the thing the librarian who wanted it mentioned, how to show the shelving location on the OPAC. I found there are a couple relevant system preferences. OpacLocationOnDetail : controls if shelving location is shown in the same column as one of the branch fields, or in its own column, or is not shown. This also mentions the item_shelving_location column in the table settings administration page, in the OPAC group, in the "holdingst" table. (Make sure it is unchecked so it is not hidden.) OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the shelving location is presented in a tab group on the search page with the item types. The other field that can be in that tab group is Collection. ...
-- Kind regards,
Alexander Wagner
Deutsches Elektronen-Synchrotron DESY Library and Documentation
Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg
phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
-- Michael Hafen Washington County School District Technology Department Systems Analyst
Hello!
I was recently looking at Shelving location actually, and this was the thing the librarian who wanted it mentioned, how to show the shelving location on the OPAC. I found there are a couple relevant system preferences.
OpacLocationOnDetail : controls if shelving location is shown in the same column as one of the branch fields, or in its own column, or is not shown.
I'll check out our settings there. I didn't know this one yet. Thanks!
OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the shelving location is presented in a tab group on the search page with the item types. The other field that can be in that tab group is Collection.
Those are indeed set up already. -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
Hi Alexander, maybe something else that could work for some of your use cases is the course reserves module. It allows you to temporarily change item values while they are in a an active course reserve and automatically changes them back when they aren't. I believe it could be useful for exhibitions or the new items shelf maybe. It also gives a nice indication in the OPAC that an item is currently in a course reserve. Some renaming of things could be achieved with jQuery/OpacUserJs. Hope this helps, Katrin On 07.03.24 14:10, Wagner, Alexander via Koha-devel wrote:
Hello!
I was recently looking at Shelving location actually, and this was the thing the librarian who wanted it mentioned, how to show the shelving location on the OPAC. I found there are a couple relevant system preferences.
OpacLocationOnDetail : controls if shelving location is shown in the same column as one of the branch fields, or in its own column, or is not shown. I'll check out our settings there. I didn't know this one yet. Thanks!
OpacAdvancedSearchTypes and AdvancedSearchTypes : controls whether the shelving location is presented in a tab group on the search page with the item types. The other field that can be in that tab group is Collection. Those are indeed set up already.
Hello Katrin!
maybe something else that could work for some of your use cases is the course reserves module.
Yepp. I actually set up something along those lines based on your comments in the chat some time ago.
It allows you to temporarily change item values while they are in a an active course reserve and automatically changes them back when they aren't. I believe it could be useful for exhibitions or the new items shelf maybe.
I think there might be some issue if the items are actually checked out while they are in such a reserve. (Our exhibitions are not some rare books or illuminated manuscripts, but the idea is to pick some theme people would probably not associate with our library holdings and encourage checkouts.) Anyway, what I did now is to set up some "courses" and I can move the items there. For the new items shelf I give them some special item type (to change the loan period) and for the others I just change location. This seems to work well. Now if an item is checked out and checked in again, it would however, keep this item type and AFAIS it's temporary location, while we'd not see on the item as such that it should go back to said location. (IOW we didn't add special markers to the books, and usually they are dropped into the cart.) In this case it would just be re-shelved to the permanent location. So, in these cases they may display a wrong location and calculate a wrong loan period, till we change the exhibition or move them from the new items shelf to their primary location by removing all items from the course reserve items. I think that this is "within the error margin", so this can work out. Especially, as at some point in time we'd always clear the reserves so items move back to their permanent location anyway. As the time span is not years but weeks and our collection is "slightly smaller than the LoC"...
It also gives a nice indication in the OPAC that an item is currently in a course reserve. Some renaming of things could be achieved with jQuery/OpacUserJs.
Yes, I was pondering to at least attack the "course reserves" name. I already noticed that I could switch of some (in this context confusing) displays via table column settings. Still, it might be worth pondering how Koha handles temporary locations vs. permanent locations. Right now the course reserves attack this issue, then there are the automatic rules to change locations upon check in (and, I think since 23.11, also at check out). There are some magics like CART and PROC, and I have a gut feeling that all this is modelling special cases around the general theme of temporary locations. Abstracting this could probably reduce magic, simplify procedures and code. Especially the CART/PROC-magic is somewhat confusing for a newbe like me. "Ah, there is _PERM_ so I could do this with _every_ location." Rules like `NEW: _PERM_` and `_BLANK_: _PERM_` didn't really work as expected. Those who can read (the docs) have a clear advantage ;) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
Hi Alexander, Welcome to the Koha community! ?? Many of the things you're trying to do can be done in Koha through some other mechanism.
E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location.
In Koha we would do this by placing a hold on the item for that patron, and then check the item in - then Koha will display it as "On hold" in the OPAC and "Waiting hold for such-and-such patron" on the Staff Intranet.
Unfortunately, the strict `not for loan` doesn't work well for us. We are open 24/7, but not staffed 24/7. IOW whatever hits the shelf can be taken. If someone checks out an item that is in principle not for loan, I'd really like to check it out, just to know who has it ;) I did not yet find a way to soften `not for loan` to something like `2 days and immediately send a recall letter`. (Current procedure.)
One way you could do this would be to define a NOTFORLOAN item type, and then edit the Circulation and Fines Rules to give that item type a loan period of 2 days with no renewals. If you want Koha to automatically send a recall letter for those that is different than the standard due/overdue notice, that would take a bit of doing when adjusting the notice template, but off the top of my head I believe it would be possible. That being said, it certainly would be nice to have more flexibility in defining temporary locations for items (such as displays or mending) - there is (at least one) bug for that in Bugzilla if you want to follow and/or comment: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962 Our library system is currently in the process of working with ByWater to sponsor/co-sponsor a feature like that. Finally, I just want to clarify that Shelving Location does indeed consist of both a "location" and "permanent location" (separate from homebranch and holdingbranch), though that's not necessarily obvious depending on where you're looking, and you're right that the distinction mostly exists for the benefit of the "magic" values of CART and PROC. I point this out partly because it can be a stumbling block in custom SQL reports...I learned this the hard way when an enterprising librarian contacted me asking why the "items list per shelving location" reports for her branch were showing so few items. It turned out that everything that had recently been checked in, and thus had a "location" of CART, was being left off the reports - which was very noticeable because she was using the reports in the first place for some inventory work, and checking in large numbers of books in the process! Emily Lamancusa (she/her) IT Specialist III Montgomery County Public Libraries (240) 777-0052 ________________________________ From: Wagner, Alexander <alexander.wagner@desy.de> Sent: Wednesday, March 6, 2024 3:11 AM To: Michael Hafen <michael.hafen@washk12.org> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Ponderings on locations Hi!
Forgive me if I add to your confusion a bit instead of clearing it up. There are actually three locations in Koha: Permanent location, current location, and shelving location. The first two only matter if you have more than one site; if you only have one site you can set them to the same value and effectively ignore them.
Indeed I did not dive into "more than one site". I do have that also, but I understood that this is modelled on the `branch` concept.
These are home branch and holding branch internally. It seems like most of what you are talking about here is the Shelving Location.
Yes. My question is mainly: how do I tell, also to patrons in the OPAC but also me if I explain the OPAC to a new patron, where to go for an item. E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location. (Currently, we add a temporary location like `Library Desk Hamburg` or `Library Desk Zeuthen` in this case.)
I'll also mention that Koha can have pseudo patrons also, these can be one of many types. For example I have an Organizational type patron category called 'Library', and I may have a 'On Display', or 'Repair room' patron in that category. This doesn't help with automatically changing the Shelving Location though.
I saw those and noticed that I can check out items. I was pondering those for items we temporarily remove from the collection. In our situation this doesn't help too much for items on some shelve though. We are open 24/7, so everyone with an access card can enter the library and take whatever is in the open shelves and even if _we_ checkout items we use the SIP-machine... IOW, even if _we_ think, that e.g. new items should be on display for a week or so you could take them. That's why I'd prefer to check items out even if this is not intended. IOW anything making things in the reading room unable to be checked out at all doesn't really work well for us.
There is also an 'after_circ_action' plugin hook. Perhaps there is, or you could have created, a Koha plugin to mangle the Shelving Location based on who an item is checked out to / returned from.
This sounds like an option to re-implement my special patrons. Thanks for the pointer. :) -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de [https://www.montgomerycountymd.gov/mcg/Resources/Images/Cybersecurity-footer...] For more helpful Cybersecurity Resources, visit: https://www.montgomerycountymd.gov/cybersecurity
Hello Emily!
Many of the things you're trying to do can be done in Koha through some other mechanism.
:)
E.g. if it has been requested and is prepared for some patron another one will not find it in the shelves, so IMHO it is a good idea to show in OPAC that it is in a different location.
In Koha we would do this by placing a hold on the item for that patron, and then check the item in
and confirm the hold, right? IOW the _status_ `on hold` describes that the item _is already_ on the shelf of items prepared for our patrons. (What we called `Library Desk HH`).
then Koha will display it as "On hold" in the OPAC and "Waiting hold for such-and-such patron" on the Staff Intranet.
So in Koha Current library: DESY Hamburg Library Location: Main Status: On hold is the same thing as Library: DESY Hamburg Library Location: Library Desk HH I'll just correct my thinking here and adopt Kohas view. :)
Unfortunately, the strict `not for loan` doesn't work well for us. We [...] immediately send a recall letter`. (Current procedure.)
One way you could do this would be to define a NOTFORLOAN item type, and then edit the Circulation and Fines Rules to give that item type a loan period of 2 days with no renewals.
This is what I actually did already together with changing all `not for loan` loan periods we have right now. I just mentioned the not for loan feature as it entered this "where is the book right now" game somewhat unexpectedly (for me). What got me confused quite a bit was that there is - `UpdateItemLocationOnCheckin`: Ok, this is plausible. If I check in an item it is in some other place. Especially, if I explicitly treat CART as a location, which is sensible. (That we didn't till now is more a failure in our current system, that I will not fix any more.) - `UpdateNotForLoanStatusOnCheckin`: This however, I found completely unrelated, cause the loan period is independent from the items location. So I played with both of them and noticed that they both also trigger displays in OPAC. Both basically use the same kind of translation tables (if status is x change it to y once an item is checked in) while I noticed that only the `UpdateNotForLoanStatusOnCheckin` managed all stages as described in the translation tables while `UpdateItemLocationOnCheckin` behaved "stange" at first sight as I got this incorrect permanent location set. I think, I now got why the `not for loan`-status entered the game, though it is still a bit strange to me and as mentioned it does not work as a work around for exhibtions, new itmes etc. (But loan periods and not for loan handling in Koha is completely different to our current system anyway, so I'll just have to adopt to Kohas view.)
If you want Koha to automatically send a recall letter for those that is different than the standard due/overdue notice, that would take a bit of doing when adjusting the notice template, but off the top of my head I believe it would be possible.
I think if I have a short loan period they'd trigger the first recall, so this should be fine. But I'll double check. (I'll have to dive a bit more into the recall procedures, as I fear not all of our patrons return their items after the 3rd notice, but that's another issue.)
That being said, it certainly would be nice to have more flexibility in defining temporary locations for items (such as displays or mending) - there is (at least one) bug for that in Bugzilla if you want to follow and/or comment: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14962
Somehow I knew that my thinking isn't too strange. Thanks for the poiner! I think 14962 is indeed pretty spot on. One thing I do not understand is, why CART and PROC have to be special in the first place. If the mapping table just works on `location` and leaves `permanent_location` alone (like it does for PROC and CART) I think things work as expected once in some final steps I map `<something>: _PERM_`. IOW I do not understand why checkin touches a permanent location that was set during cataloguing as some conscious decision: we shelve this item in the special reading room etc.
Our library system is currently in the process of working with ByWater to sponsor/co-sponsor a feature like that.
As mentioned, unless I overlook something deep in some other areas not too much feature may be required, but more removal of magic. 14962 describes yet another location, but I think this is not required as `items.location` is basically the described temp-location. But I am to new to Koha to understand all implications.
Finally, I just want to clarify that Shelving Location does indeed consist of both a "location" and "permanent location" (separate from homebranch and holdingbranch), though that's not necessarily obvious depending on where you're looking, and you're right that the distinction mostly exists for the benefit of the "magic" values of CART and PROC.
So, if all automagic juggling works on `items.location` and the rules somehow know when to clear `items.location`...
I point this out partly because it can be a stumbling block in custom SQL reports...I learned this the hard way when an [...] in large numbers of books in the process!
I see your point. Noted down. Indeed, I stumbled there as well once I inspected the items-table. -- Kind regards, Alexander Wagner Deutsches Elektronen-Synchrotron DESY Library and Documentation Building 01d Room OG1.444 Notkestr. 85 22607 Hamburg phone: +49-40-8998-1758 e-mail: alexander.wagner@desy.de
participants (4)
-
Katrin Fischer -
Lamancusa, Emily -
Michael Hafen -
Wagner, Alexander