Multiple branch support

[jfmartinezm]

Sometimes libraries that belong to the same library network (branches located on different buildings) could benefit from sharing the same Libki server, but would still need to have access only to their own assets (clients, printjobs, etc).

One way to achieve that is by using the multi-tenant capabilities of Libki, but as I see on #232 that feature is troublesome and is probably going to be removed. Besides, the branches are not really different tenants, as they belong to the same network.
Another solution would be to use completely separated Libki instances for each of the branches, but that would mean running and maintaining different servers/containers and multiple database instances (or multiple databases, at least). Extracting information for that separated databases (e.g. statistics for the whole network) would be more complicated then.

Perhaps there could be some way of filtering the items (clients, printjobs, etc) for admin users, so that they only get access to items on certain locations, or named following a certain pattern.

[kylemhall]

Multi-building support is in the planning stages. The plan is to either modify the instance column such that it's no longer a hidden field, but just a "parent location", or to remove it and add a 'sub-location' column.

[jfmartinezm]

Ok, so in that case filtering would be done depending on an additional field, either the old instance field repurposed as parent location, or a new sub-location field. I guess in any of that cases, the parent or sub-location would have to be added to the client settings just as it happens with the current location field.

I was thinking about using the current location field to specify that parent or sub location: instead of it being a single, flat value (like "Floor 2"), it could be used as a hierarchical value (like "Main Branch.Floor 2", or even "Main Branch.Floor 2.Guest area", etc. Then, admin users would have a "location filter" field that would filter the items they can see: "Main Branch.*" for whole branch admins, "Main Branch.Floor 2.*" for Floor 2 staff, etc. Superadmins could have "*" as a filter so they have access to all entries.

What do you think? How hard would it be to implement a scheme like that?

[jfmartinezm]

Are there any news on the subject of multi-building support? I have tried to implement the idea I had, but it turns out I had assumed Users had a location field, which is not the case, making it very hard to implement it the way I had in mind.

[kylemhall]

Adding multiple branch support would not change affect users. It sounds like you want each site to have a separate set of users. Is that correct?

[jfmartinezm]

Not really, in our network the users should be common to all libraries. I was just going to use a user location field for specifying a filter that would be applied to admin users when they use the admin interface, and try to match that with the location field for clients so that an admin user would only see clients from its user location.

As that would require adding the location field to users, maybe we could add instead a library field to both clients and users (and possibly print jobs), so that admin users assigned to a library would only see the clients and printjobs from its own assigned branch.

[kylemhall]

Ah, I can see how that would be useful!

[sekjal]

I've been looking at this from the Location hierarchy angle for a while, and want to move forward with it in 2026. Propose changes:

1. Locations become a first class entity in Libki, with distinct properties like:
   • name
   • code
   • hours of operation
   • parent location (optional)
   • location-specific settings, like whether Clients in this Location are reservable or FCFS, etc
2. part of setting up Libki would be creating a default 'root' Location that has all the fallback settings for your site. If no sublocations are used, everything will operate as it does currently
3. existing installs would have their instances converted to parent locations, and their current locations associated properly
4. both the admin and public interfaces would need a way to drill down/filter so one could see both a high-level view of all clients/prints, but also only those for a specific parent location
5. administrator accounts could be assigned a default location filter. This would only set a default, not restrict the ability to change locations. To do that, we'd need to re-evaluate the permissions system in Libki first.
6. Printers could also be associated with Locations, though we'd need to think about how web uploads would be positioned within the hierarchy. And printer Locations may not be 1-to-1 with PC Locations

[jfmartinezm]

I'm glad to see this issue actively worked on, as it has been kind of a show-stopper for our organization to deploy this solution. The proposed changes seem right to me, although I think the relationship between location and library should be clarified: ¿does a location belong to a library, and clients and printers belong to that location, or do clients and printers belong to locations independently from the library?

[sekjal]

I had envisioned no particular distinction between "Location" and "Library". Locations with no parent would probably be often mapped to library buildings, and may have multiple layers of sub- and sub-sub Locations within them. Clients would continue to belong to a single Location, but could inherit settings and hours from their parent or other ancestors. Viewing the Clients for a library would show all the Locations within it (similar to how we do now, but with UI consideration for 'taller' hierarchies).

Example:

Library A

• First Floor
  • Children's room
  • Computer lab
• Second Floor
  • North Side
  • South Side

Library B

• Reference Area
• Public PCs

Library C

Library D

• First Floor
• Second Floor
  • Computer Lab 1
  • Computer Lab 2
  • Print Corral
• Annex

It would be possible, then, for admins to have a specific Library Location as their default view, but the Computer Lab manager at Library A could have that sublocation as their default view if it makes more sense for their daily work.

Printers would also be associated with Locations, but there could be cases where they are separated from the PCs (see Library D). This system would be flexible enough to accommodate for most building layouts, I think.

[jfmartinezm]

Ok, so the location makes reference to the building and the physical location inside it, not neccesarily related to the branch as seen by the ILS, if I understand correctly. I also think this system could work for most organizations, at first sight it would seem that it could apply to ours, as it is quite flexible indeed.

[sekjal]

Correct. We want Libki to continue to be able to function without any ILS backing, but of course to benefit from it. Perhaps we could have options where, if the authentication mechanism to the ILS returns a branch code that matches on configured in Libki, that that branch is used as the default view, both for the admin and public sides

[jfmartinezm]

That would be nice. Perhaps it could be implemented by adding an optional field to the Location entity, such as Branch Code. That way, if the ILS returns the branch code on authentication, the default view could be automatically filtered to the matching Location (and possibly sub-locations).