Bug 32748 - Library limitations will cause data loss when editing items
Summary: Library limitations will cause data loss when editing items
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low major with 1 vote (vote)
Assignee: Thibaud Guillot
QA Contact: Testopia
URL:
Keywords:
Depends on: 19361
Blocks:
  Show dependency treegraph
 
Reported: 2023-01-30 16:26 UTC by Katrin Fischer
Modified: 2024-01-23 10:50 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 32748: Prevent data erasing when editing item (2.43 KB, patch)
2023-03-20 11:36 UTC, Thibaud Guillot
Details | Diff | Splinter Review
Bug 32748: Prevent data erasing when editing item (2.49 KB, patch)
2023-03-21 18:24 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 32748: Prevent data erasing when editing item (5.85 KB, patch)
2023-04-24 12:48 UTC, Thibaud Guillot
Details | Diff | Splinter Review
Bug 32748: Prevent data erasing when editing items (6.79 KB, patch)
2023-06-05 13:05 UTC, Thibaud Guillot
Details | Diff | Splinter Review
Bug 32748: Prevent data erasing when editing items (6.79 KB, patch)
2023-07-28 14:09 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 32748: (follow-up) Fix perlcritic error (889 bytes, patch)
2023-07-28 14:09 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 32748: (follow-up) Perltidy (2.90 KB, patch)
2023-07-28 14:09 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 32748: (follow-up) Fix terminology: branches > libraries (1.51 KB, patch)
2023-07-28 14:09 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2023-01-30 16:26:47 UTC
Moving this from bug 31422 where another issue was fixed to a new bug report:

The library limitations are used to limit down the selection in pull downs in several spots. If you are editing data from library B while logged in at library A, doing so might result in data loss as the value stored in the modified object might be missing from the drop downs your user sees.

Example 1: Item values

Itemtype: BK Books - limited to Centerville
AV LOC: FIC Fiction - limited to Centerville
Your user: logged in for Centerville

* Edit an item and make sure it uses the itemtype Books and location Fiction.
* Switch library to any but Centerville.
* Edit item: Both item type and location drow downs will be empty.
* Saving now will empty out itemtype (if not set mandatory) and location resulting in data loss.



I initially thought that bug 20256 might help here, but it won't as there is a mismatch of one feature checking the login library and the other checking the home library of the staff patron.
Comment 1 Katrin Fischer 2023-01-30 16:27:38 UTC
The goal should be to have a 'keep current' option like we have for funds on the receive screen that you are not allowed to use.
Comment 2 Thibaud Guillot 2023-03-16 13:17:19 UTC
Hello Katrin,

I've worked on this recently, but I don't know how to deal with this new value in dropdown. Should the form entry be disabled to prevent value change by another library? Because this is the real risk in the end. 

Note that there is also the same kind of behavior on serials, on location input.
I am curious to have the opinion of the community on these behaviors.
Comment 3 Katrin Fischer 2023-03-16 14:09:24 UTC
Hi Thibaud,

thanks a lot for taking this one on!

I think they should have a pull down with all values "allowed" for them + the current one.

We do something similar in acq when you receive an order where you don't have access to the fund. The fund displays as "fund (current)" and you can change it to another or keep it for that order.

And we do the same for patron categories: If a patron category is limited to a specific library and you edit the patron, you also have the current ones now + any that you are allowed to set.

So I think being consistent would be great and also make sense.
Comment 4 Thibaud Guillot 2023-03-20 11:36:38 UTC
Created attachment 148409 [details] [review]
Bug 32748: Prevent data erasing when editing item

When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.

This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Test plan :

1) Edit an item with one of these fields has an authorized value from
another library.
2) See that you don't get this value on 'edit'
3) Apply this patch
4) Refresh and do step 1
5) Now you have the value in dropdown list
Comment 5 Michaela Sieber 2023-03-21 18:20:01 UTC
(In reply to Thibaud Guillot from comment #4)
> Created attachment 148409 [details] [review] [review]
> Bug 32748: Prevent data erasing when editing item
> This patch add current value to the dropdown list even if it comes from an
> authorized value of another library.
> 

Merci beaucoup Thibaud!

Everything works as expected.

I tested editing existing items and adding new items with different libraries for

item type
   Computer Files (=CF) : 1 library limitation (Fairfield)

Authorized values
 CCODE
   Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin)
 
 LOC
   Audio visual (=AV) : 1 library limitation (Institut Protestant de Théologie)


in Biblibre sandbox b32748.
Comment 6 Biblibre Sandboxes 2023-03-21 18:24:07 UTC
Created attachment 148491 [details] [review]
Bug 32748: Prevent data erasing when editing item

When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.

This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Test plan :

1) Edit an item with one of these fields has an authorized value from
another library.
2) See that you don't get this value on 'edit'
3) Apply this patch
4) Refresh and do step 1
5) Now you have the value in dropdown list

Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Comment 7 Thibaud Guillot 2023-03-22 08:00:44 UTC
(In reply to Michaela Sieber from comment #5)
> (In reply to Thibaud Guillot from comment #4)
> > Created attachment 148409 [details] [review] [review] [review]
> > Bug 32748: Prevent data erasing when editing item
> > This patch add current value to the dropdown list even if it comes from an
> > authorized value of another library.
> > 
> 
> Merci beaucoup Thibaud!
> 
> Everything works as expected.
> 
> I tested editing existing items and adding new items with different
> libraries for
> 
> item type
>    Computer Files (=CF) : 1 library limitation (Fairfield)
> 
> Authorized values
>  CCODE
>    Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin)
>  
>  LOC
>    Audio visual (=AV) : 1 library limitation (Institut Protestant de
> Théologie)
> 
> 
> in Biblibre sandbox b32748.

Great, thanks Michaela ;)
Comment 8 Jonathan Druart 2023-03-23 09:45:31 UTC
We need to keep the same behaviour as bug 31422 and add the tooltip in my opinion.

Also adding one more query per AV is counter productive here, given all the work we made to cache things...
Comment 9 Jonathan Druart 2023-03-23 09:48:06 UTC
You could modify GetAuthorisedValues to get a new "no_limit" parameter. If set, you ignore the limit on the branchcode and return the list of AVs (all of them) with an additional key containing the limit info (eg. _restricted => 1).
Then it will be easy to ignore the restricted one in the template, and add the tooltip in case it's the current value.
Comment 10 Thibaud Guillot 2023-04-24 12:48:58 UTC
Created attachment 150155 [details] [review]
Bug 32748: Prevent data erasing when editing item

When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.

This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Test plan :

1) Edit an item with one of these fields has an authorized value from
another library.
2) See that you don't get this value on 'edit'
3) Apply this patch
4) Refresh and do step 1
5) Now you have the value in dropdown list and a tooltip info
Comment 11 Thibaud Guillot 2023-04-24 12:53:15 UTC
Hello,

I followed your advice to rework the patch to change the behavior of the GetAuthorisedValues function and then use the values obtained to target authorised values from other librairies.
 
I have however the problem concerning the icon that I can't see :-/ (if anyone has an idea ?)

I submit you this patch to know if I'm going in the right direction. 
Thanks for your future feedbacks
Comment 12 Michaela Sieber 2023-04-26 05:27:29 UTC
(In reply to Thibaud Guillot from comment #11)
> 
> I submit you this patch to know if I'm going in the right direction. 
> Thanks for your future feedbacks

Hi Thibaud,

I wanted to test the new patch, but the sandbox does not start and an error occurs:
Template process failed: undef error - C4::Koha::GetAuthorisedValues(): DBI Exception: DBD::mysql::st execute failed: 'koha_b32748.av.category' isn't in GROUP BY at /kohadevbox/koha/Koha/Template/Plugin/AuthorisedValues.pm line 39
 at /kohadevbox/koha/C4/Templates.pm line 127

for more information see:

https://staff-b32748.sandboxes.biblibre.eu/
Comment 13 Mathieu Saby 2023-05-02 10:28:57 UTC
Hi
We asked Biblibre to fix that bug a few monthes ago so I would like to add some comments from a librarian point of view.

I am not completely sure of the predicted behavior of the patch, but please consider this situation : 
We have 2 libraries:
- the library A has only 2 locations LOCA-1 and LOCA-2
- the library B has only 2 locations LOCB-1 and LOCB-2.
An item's homebranch is library A, location LOCA-1.
The librarian is connected to library B

The location LOCA-1 should be preserved when the librarian edits the item in order to change an other item field.
But he must not be allowed to change the location to LOCB-1 or LOCB-2. It would result in a data inconsistency because those location are not valid for Library A.

Is it the behavior you are planning ?
Comment 14 Michaela Sieber 2023-05-02 11:45:36 UTC
(In reply to mathieu saby from comment #13)
> Hi
> We asked Biblibre to fix that bug a few monthes ago so I would like to add
> some comments from a librarian point of view.
> 
> I am not completely sure of the predicted behavior of the patch, but please
> consider this situation : 
> We have 2 libraries:
> - the library A has only 2 locations LOCA-1 and LOCA-2
> - the library B has only 2 locations LOCB-1 and LOCB-2.
> An item's homebranch is library A, location LOCA-1.
> The librarian is connected to library B
> 
> The location LOCA-1 should be preserved when the librarian edits the item in
> order to change an other item field.
> But he must not be allowed to change the location to LOCB-1 or LOCB-2. It
> would result in a data inconsistency because those location are not valid
> for Library A.
> 
> Is it the behavior you are planning ?


Hi Mathieu,

these patches are for preventing data loss!

Problem TODAY  : If a librarian connected to library B is editing for example the item call number of an item with homebranch library A he will not be able to see the value location LOCA-1.
Saving the item record will result in data loss because the empty location field in the item form overwrites the existing value LOCA-1.
Comment 15 Mathieu Saby 2023-05-03 12:32:56 UTC
Yes, the data loss is a nasty bug and must be fixed.
Perhaps my embarrassment arises from the fact that Koha relies exclusively on the librarian's connection library to filter the possible locations. Most of the time this is not a problem, but if the item's homebranch is different from the connexion library, it leads to a behavior that can be inconvenient or surprising.

One could imagine that Koha relies dynamically on the homebranch defined in the form to determine the possible locations, like some other ILS. This has not been the initial choice of the community, but do you think it could be worth thinking about (in an other bug...) ?
Comment 16 Jonathan Druart 2023-05-03 13:52:57 UTC
Failing QA for comment 12. Thibaud, avoid GROUP_CONCAT, and just don't display the libraries from where the value is limited.

Also you should cache using the branchcode in the cache key, or you will get random wrong results.
Comment 17 Katrin Fischer 2023-05-03 21:35:46 UTC
(In reply to Jonathan Druart from comment #16)
> Failing QA for comment 12. Thibaud, avoid GROUP_CONCAT, and just don't
> display the libraries from where the value is limited.
> 
> Also you should cache using the branchcode in the cache key, or you will get
> random wrong results.

Maybe to explain: GROUP_CONCAT creates an issue with <strict_sql_modes>1</strict_sql_modes>. If you have turned that off in koha-conf.xml you'll not see the error until you turn it back on.
Comment 18 Thibaud Guillot 2023-06-05 13:05:27 UTC
Created attachment 151989 [details] [review]
Bug 32748: Prevent data erasing when editing items

When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.

This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Test plan :

1) Edit an item with one of these fields has an authorized value from
another library.
2) See that you don't get this value on 'edit'
3) Apply this patch
4) Refresh and do step 1
5) Now you have the value in dropdown list and a tooltip info
Comment 19 Thibaud Guillot 2023-06-05 13:13:30 UTC
Hello everyone,

I followed your advices and removed the display of the branchcode where the values come from (and therefore the GROUP_CONCAT). I hope it can be tested by as many people as possible :-)

Jonathan : What do you mean by adding the branchcode into the cache key? The branchcode from which the VAs originate is not accessible until the cached string is defined. Why should I get random results? Thanks for the clarification
Comment 20 Jonathan Druart 2023-06-06 10:16:05 UTC
(In reply to Thibaud Guillot from comment #19)
> Jonathan : What do you mean by adding the branchcode into the cache key? The
> branchcode from which the VAs originate is not accessible until the cached
> string is defined. Why should I get random results? Thanks for the
> clarification

Hum forget that, branch_limit is part of the cache key. I cannot remember what I meant but that does not seem correct.
Comment 21 Michaela Sieber 2023-06-12 20:53:20 UTC
(In reply to Thibaud Guillot from comment #18)
> Created attachment 151989 [details] [review] [review]
> Bug 32748: Prevent data erasing when editing items
> 

Sorry, but Patch doesn't apply :/

it was possible to select location and collection (authorized values) of other Libraries and the dropdown was not limited.

And there is a new problem when an item type is limited to a library. 
If you edit the item and you are logged in with another library there is a message in the item type field  "The current value CF is not configured for the authorised value category controlling this subfield"
which I guess is very confusing for end users.


You can check it here:
https://staff-b32748.sandboxes.biblibre.eu/cgi-bin/koha/cataloguing/additem.pl?op=edititem&biblionumber=58&itemnumber=973&searchid=#edititem

I tested editing existing items and adding new items with different libraries for

item type
   Computer Files (=CF) : 1 library limitation (Fairfield)

Authorized values
 CCODE
   Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin)
 
 LOC
   Audio visual (=AV) : 1 library limitation (Institut Protestant de Théologie)
Comment 22 Thibaud Guillot 2023-07-03 07:15:12 UTC
(In reply to Michaela Sieber from comment #21)
> (In reply to Thibaud Guillot from comment #18)
> > Created attachment 151989 [details] [review] [review] [review]
> > Bug 32748: Prevent data erasing when editing items
> > 
> 
> Sorry, but Patch doesn't apply :/
> 
> it was possible to select location and collection (authorized values) of
> other Libraries and the dropdown was not limited.
> 
> And there is a new problem when an item type is limited to a library. 
> If you edit the item and you are logged in with another library there is a
> message in the item type field  "The current value CF is not configured for
> the authorised value category controlling this subfield"
> which I guess is very confusing for end users.
> 
> 
> You can check it here:
> https://staff-b32748.sandboxes.biblibre.eu/cgi-bin/koha/cataloguing/additem.
> pl?op=edititem&biblionumber=58&itemnumber=973&searchid=#edititem
> 
> I tested editing existing items and adding new items with different
> libraries for
> 
> item type
>    Computer Files (=CF) : 1 library limitation (Fairfield)
> 
> Authorized values
>  CCODE
>    Non-fiction (=NFIC) : 2 library limitations (Centerville, Franklin)
>  
>  LOC
>    Audio visual (=AV) : 1 library limitation (Institut Protestant de
> Théologie)

Hello Michaela,

Thanks for your test and feedback, the case you specify is already pushed in master, my code doesn't add this message. I can understand the confusion, but should we fix this message on another bz or am I proposing a correction here?
Comment 23 Katrin Fischer 2023-07-28 14:09:06 UTC
Created attachment 154039 [details] [review]
Bug 32748: Prevent data erasing when editing items

When we set an authorised value linked to one library,
users who do not belong to this library do not get the
value and can therefore overwrite it.

This patch add current value to the dropdown list even if it comes from an authorized value of another library.

Test plan :

1) Edit an item with one of these fields has an authorized value from
another library.
2) See that you don't get this value on 'edit'
3) Apply this patch
4) Refresh and do step 1
5) Now you have the value in dropdown list and a tooltip info
Comment 24 Katrin Fischer 2023-07-28 14:09:08 UTC
Created attachment 154040 [details] [review]
Bug 32748: (follow-up) Fix perlcritic error
Comment 25 Katrin Fischer 2023-07-28 14:09:11 UTC
Created attachment 154041 [details] [review]
Bug 32748: (follow-up) Perltidy
Comment 26 Katrin Fischer 2023-07-28 14:09:14 UTC
Created attachment 154042 [details] [review]
Bug 32748: (follow-up) Fix terminology: branches > libraries
Comment 27 Katrin Fischer 2023-07-28 14:11:21 UTC
Trying to have a look at this with a set of fresh eyes :)

I've written some follow-ups for coding guidelines and to get the QA test tools green, but the behavior is not quite right yet and this will need another look.

Test setup:
* CCODE: REF - amended description with -Fairfield and limited to Fairfield library
* LOC: AV - amended description, limited to Fairfield
* Itemtype: BKS - amended description, limited to Fairfield
* Updated Henry from Midway to only have catalog and cataloguing permissions
* I am testing with an item that CCODE = REF and LOC = NOT AV, itemtype BKS


WITHOUT PATCH / BEFORE

1) Edit item form

* Henry (Midway)
  * CCODE of the item is REF: it shows in the pull down, but marked as: Not an authorised value
    
    /!\ I believe this is a separate bug caused by bug 19361.
    It should not show as non-existing, but as limited. Same for itemtype.

  * LOC: AV is missing from the list. 
  * BK: (not an authorised value)

* Superlibrarian (Centerville) 
  * CCODE of the item if REF: Not an authorised value.
  * LOC: AV is missing.
  * Itype: BK (not an authorised value)

= Behaviour is the same for superlibrarians and users with limited permissions.

* Superlibrarian (Fairfield, login library)
  * CCODE, LOC and itype display normally.

2) Edit record form 

* Itype is not limited by branch and visible for Henry and superlibrarian.

  /!\ A different/new bug?


WITH PATCHES / AFTER

1) Edit item form

* Henry (Midway)
  * (improved) CCODE: It now shows with description and warning sign. 
  * (wrong) LOC: The limited value is now in the pull down list. It should not be as the item is not using it.
  * (unchanged, wrong) BK: (not an authorised value). This should show the same as CCODE.

* Superlibrarian (Fairfield)
  * (unchanged) CCODE, LOC and itype display normally.

2) Edit record form 

*  (unchanged) Itype is not limited by branch and visible for Henry and superlibrarian. 


SUMMARY

I think we need to fix 2 things:

* The AV should only display in the list, if it's already used by the item. Otherwise it should still remain hidden. This is the behaviour we have for category codes on the patron edit forms.
* It looks like the code doesn't take the 'false' AV like itemtype into account, but it should.
Comment 28 Thibaud Guillot 2024-01-18 14:02:20 UTC
Hi Katrin,

Sorry for the delay in my reply. I've gone back over the code a bit, concerning the presence of the value if it's not the current value, I've taken a look at the form for modifying the categorycode of a borrower and the value, even if it's limited to a branch, does appear in the list... maybe it's a recent patch, I seemed to have seen a few things that dealt with this but I can't find them :/

Could we add the disabled attribute to the entry to display it all the same, or should we stick with "hidden"? 


On the other hand, I don't understand your sentence "It looks like the code doesn't take the 'false' AV like itemtype into account, but it should." I'm calling the original GetAuthorisedValues function with an extra parameter, but it didn't retrieve the basic itemtypes, so I'd like to ask you to clarify this.

Thanks a lot!
Comment 29 Katrin Fischer 2024-01-22 21:29:32 UTC
(In reply to Thibaud Guillot from comment #28)
> Hi Katrin,
> 
> Sorry for the delay in my reply. I've gone back over the code a bit,
> concerning the presence of the value if it's not the current value, I've
> taken a look at the form for modifying the categorycode of a borrower and
> the value, even if it's limited to a branch, does appear in the list...

That should not be the case. I quickly retested:
* My user's login branch and home library is: Centerville
* Patron category "B - Board" is limited to Franklin
* Create a new patron: Board doesn't show
* Edit an existing patron with another patron category: Board doesn't show
* Edit a patron with Board category: Board appears in the list of options (but the nice little icon and text have moved all the way to the left... maybe with the staff re-design. See bug 31422)

Another area where the "keep current" is implemented really nicely is funds. If you receive an order with a fund you are not allowed to use for ordering, it will still show up in the list on receive and be marked as "current". 

To see this, something like this should work:
* Create an order line with using fund X
* Set the fund to be limited by library
* set the fund to be owned by a library that is not yours
* Make sure your user is not superlibrarian and doesn't have budget_manage_all
* Receive the order...

> maybe it's a recent patch, I seemed to have seen a few things that dealt
> with this but I can't find them :/
> 
> Could we add the disabled attribute to the entry to display it all the same,
> or should we stick with "hidden"? 

One big motivation for libraries to use library limitations is 'shrinking the list' for better usability. 
So yes, we do want to hide and only display what is absolutely necessary.


> On the other hand, I don't understand your sentence "It looks like the code
> doesn't take the 'false' AV like itemtype into account, but it should." I'm
> calling the original GetAuthorisedValues function with an extra parameter,
> but it didn't retrieve the basic itemtypes, so I'd like to ask you to
> clarify this.

I think maybe we could deal with this separately as it might be a different part of the code?

What I meant is that when setting up the item form in the bibliographic framework, you will set up the authorised values "itemtypes" and "branches" to create the item type and home and holding branch pull downs. Re-thinking this, we could deal with these separately I think - especially since only itemtypes are 'library limitable'.
Comment 30 Thibaud Guillot 2024-01-23 10:50:57 UTC
Thank you for your time and feedback Katrin, by "hide" do you mean that it would be possible to assign the "hidden" attribute to the element? In order to retrieve it anyway and for libraries that would like to make it appear they can do so via intranetUserJs for example.(In reply to Katrin Fischer from comment #29)
> (In reply to Thibaud Guillot from comment #28)
> > Hi Katrin,
> > 
> > Sorry for the delay in my reply. I've gone back over the code a bit,
> > concerning the presence of the value if it's not the current value, I've
> > taken a look at the form for modifying the categorycode of a borrower and
> > the value, even if it's limited to a branch, does appear in the list...
> 
> That should not be the case. I quickly retested:
> * My user's login branch and home library is: Centerville
> * Patron category "B - Board" is limited to Franklin
> * Create a new patron: Board doesn't show
> * Edit an existing patron with another patron category: Board doesn't show
> * Edit a patron with Board category: Board appears in the list of options
> (but the nice little icon and text have moved all the way to the left...
> maybe with the staff re-design. See bug 31422)
> 
> Another area where the "keep current" is implemented really nicely is funds.
> If you receive an order with a fund you are not allowed to use for ordering,
> it will still show up in the list on receive and be marked as "current". 
> 
> To see this, something like this should work:
> * Create an order line with using fund X
> * Set the fund to be limited by library
> * set the fund to be owned by a library that is not yours
> * Make sure your user is not superlibrarian and doesn't have
> budget_manage_all
> * Receive the order...
> 
> > maybe it's a recent patch, I seemed to have seen a few things that dealt
> > with this but I can't find them :/
> > 
> > Could we add the disabled attribute to the entry to display it all the same,
> > or should we stick with "hidden"? 
> 
> One big motivation for libraries to use library limitations is 'shrinking
> the list' for better usability. 
> So yes, we do want to hide and only display what is absolutely necessary.
> 
Thank you for your time and feedback Katrin, by "hide" do you mean that it would be possible to assign the "hidden" attribute to the element (just to be clearer) ? In order to retrieve it anyway and for libraries that would like to make it appear they can do with "intranetUserJs" for example.
> 
> > On the other hand, I don't understand your sentence "It looks like the code
> > doesn't take the 'false' AV like itemtype into account, but it should." I'm
> > calling the original GetAuthorisedValues function with an extra parameter,
> > but it didn't retrieve the basic itemtypes, so I'd like to ask you to
> > clarify this.
> 
> I think maybe we could deal with this separately as it might be a different
> part of the code?
> 
> What I meant is that when setting up the item form in the bibliographic
> framework, you will set up the authorised values "itemtypes" and "branches"
> to create the item type and home and holding branch pull downs. Re-thinking
> this, we could deal with these separately I think - especially since only
> itemtypes are 'library limitable'.

Okay, thanks for clarifying that point :)