Comment 11 for bug 1744756

I love this feature, and I know our circ staff will love it too! I do have a couple of questions.

1. Using a Concerto database, I was able to create a tree for CONS and for SYS2, but these trees had no impact on the patron registration interface. Is that expected? It would be highly useful if a tree owned by the CONS served as a default for all child org units. A tree for a specific org unit could then override the one created at the consortium level. This would be highly useful for our consortium with 150+ libraries where the majority of libraries are probably using the same permission groups because it wouldn't be required to create a tree for each branch-level org unit. I imagine it might also be useful for creating a tree for an entire system when the branch libraries all use the same permission groups. If the trees are not supposed to work that way, then I would recommend removing org units that cannot be used as registered workstations from the selector in the admin interface.

2. The docs say 'If you want a particular Org Unit to not have access to specific entries, you may remove an entry. Removing an entry will remove it from view. The entry will remain in the database, marked as disabled. Select an entry and press the *Remove* button.'

However, this isn't what I'm seeing. When I click the remove button in the interface, it removes the entry from the table, thereby removing the entry from the view. It has the same visible effect for the end user, but the only way I've been able to set an entry to disabled is directly through the database. Maybe the disabled field isn't needed?