Repository navigation
Multiple branch support #306
Description
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.
Activity
kylemhall commentedon May 24, 2023
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 commentedon May 25, 2023
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 commentedon Nov 5, 2024
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
locationfield, which is not the case, making it very hard to implement it the way I had in mind.kylemhall commentedon Nov 7, 2024
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 commentedon Nov 7, 2024
Not really, in our network the users should be common to all libraries. I was just going to use a user
locationfield for specifying a filter that would be applied to admin users when they use the admin interface, and try to match that with thelocationfield for clients so that an admin user would only see clients from its user location.As that would require adding the
locationfield to users, maybe we could add instead alibraryfield 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 commentedon Nov 7, 2024
Ah, I can see how that would be useful!