https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27721 Bug ID: 27721 Summary: Circulation Workflow (Statuses) Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: cbrannon@cdalibrary.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com It would be great if there were some kind of centralized workflow for processing items that would allow libraries to handle items the way they need to at each branch. Right now we have rules, and then we have statuses. There are some workflows for statuses peppered throughout the preferences, but nothing centralized, and far too limiting. I think some of these settings could be centralized through a common workflow interface, similar to (or maybe combined with) UpdateItemLocationOnCheckin, and be given some better flexibility. Please understand that I am just throwing this out there for a discussion. Some of these ideas might be redundant and might even be too complex a change for Koha. But, for the sake of discussion and brainstorming, what if we could define common triggers and actions, and allow libraries to combine these with common elements? Basically, it would be great to have a framework in which we could define what elements would trigger what kind of actions, and in what order. Here is where I am coming from. We have a library that would like to create a status for lost items that are in collections. Easy enough. We would like to make sure that when the item status is changed from long overdue to lost and in collections that the fee is not removed. We would also like it if an item with this status were checked in at some or all libraries, it would pause the check in with a message stating that it is in collections, are you sure you want to check this item in? Maybe we just simply need more status preferences? But, it seems we have a few peppered through the settings as it is, and it would be great if we had these in a central framework where we could see them all and prioritize them and have more options as to how they work. Does this status charge? Does it refund? Should it be confirmed? Should it block? Should it reroute? Should it notify a staff member? Should it go to a staff member for processing? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.