Evergreen

Bug #1773417
Comment #29

Comment 29 for bug 1773417

Revision history for this message

Dan Wells (dbw2) wrote on 2018-06-13:

#29

Ok, latest changes are up, 3 new commits:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

working/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

Commit #1 is just a revert of removing the record-level menu option. I could have rolled this into #2, but thought this would be easier this way to squash that diversion away eventually.

Commit #2 is the bulk of the changes. This commit attempts to achieve the goals of both simplification and feature completeness/flexibility. In brief, it continues along the path Mike had started, that is, limit the number of marking and transfer options, then have the code decide the right action to take given the circumstances.

There are now just two "marking" actions, one at the record level, one at the holdings level. The holdings level mark will automatically mark the destination as specifically as possible from the selected row, which means either to the library or call number (vol) level.

We are also now down to two transfer options: transfer the selected item, or transfer the selected volume. Either option will use as much of the given context as possible, then fill in any blanks with reasonable defaults and actions.

For any studying the actual code, as part of the change, a number of functions and variables are also renamed. This is all done for clarification, and in most cases is due to the variable or function now being used more generally (i.e. it is used in both the item and vol context, so it is confusing to be named 'volume_transfer_target', etc.). This commit also clears up a fair bit of now redundant and unused code.

Finally, I added a third commit to fix bugginess in transferring from item status which came up in testing, even though it exists in current master and is really a separate issue. (It just makes some sense to strike while the iron is hot.) Item status transfer really needs to be revamped similar to what we're doing above, as it has both usability and code-duplication issues, but if we let this branch leak too much into other cataloging bugs, we might be here quite a while longer :)

Actually, one more thing I should note. Many existing cataloging functions don't give great feedback to the user, and these are no exception (in master and in this branch). I spent an hour or two attacking that, but ultimately decided to hold that back to again try to limit scope creep of this branch. But if/when this gets in, I've got some of that improvement stashed away and ready to go!

Dan

Ok, latest changes are up, 3 new commits:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

working/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

Commit #1 is just a revert of removing the record-level menu option.  I could have rolled this into #2, but thought this would be easier this way to squash that diversion away eventually.

Commit #2 is the bulk of the changes.  This commit attempts to achieve the goals of both simplification and feature completeness/flexibility.  In brief, it continues along the path Mike had started, that is, limit the number of marking and transfer options, then have the code decide the right action to take given the circumstances.

There are now just two "marking" actions, one at the record level, one at the holdings level.  The holdings level mark will automatically mark the destination as specifically as possible from the selected row, which means either to the library or call number (vol) level.

We are also now down to two transfer options: transfer the selected item, or transfer the selected volume.  Either option will use as much of the given context as possible, then fill in any blanks with reasonable defaults and actions.

For any studying the actual code, as part of the change, a number of functions and variables are also renamed.  This is all done for clarification, and in most cases is due to the variable or function now being used more generally (i.e. it is used in both the item and vol context, so it is confusing to be named 'volume_transfer_target', etc.).  This commit also clears up a fair bit of now redundant and unused code.

Finally, I added a third commit to fix bugginess in transferring from item status which came up in testing, even though it exists in current master and is really a separate issue.  (It just makes some sense to strike while the iron is hot.)  Item status transfer really needs to be revamped similar to what we're doing above, as it has both usability and code-duplication issues, but if we let this branch leak too much into other cataloging bugs, we might be here quite a while longer :)

Actually, one more thing I should note.  Many existing cataloging functions don't give great feedback to the user, and these are no exception (in master and in this branch).  I spent an hour or two attacking that, but ultimately decided to hold that back to again try to limit scope creep of this branch.  But if/when this gets in, I've got some of that improvement stashed away and ready to go!

Dan