Kyle, thanks for reporting and working out a solution to this bug. I wonder, though, whether this fix is the right direction to go.
It seems at one time the hold "blob" had the notes attached, then they disappeared. Tracing the problem back a step further, then, it looks like the hold fetching code has a logic error on the server side. Basically, it is hiding staff notes from the staff instead of the user (and vice versa).
Here is a branch to address that problem, which in turn fixes the client display:
In addition, I have pushed an additional commit on this branch to allow public notes to be seen in appropriate cases. While not strictly part of this bug, it seems sensible to include it, provided my understanding of the original intentions are correct.
Finally, I didn't check all the variations of this bug, so please report back if this doesn't solve them all, and we can see what additional work needs to be done.
Kyle, thanks for reporting and working out a solution to this bug. I wonder, though, whether this fix is the right direction to go.
It seems at one time the hold "blob" had the notes attached, then they disappeared. Tracing the problem back a step further, then, it looks like the hold fetching code has a logic error on the server side. Basically, it is hiding staff notes from the staff instead of the user (and vice versa).
Here is a branch to address that problem, which in turn fixes the client display:
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ dbwells/ hold_blob_ note_fetch
working/ user/dbwells/ hold_blob_ note_fetch
In addition, I have pushed an additional commit on this branch to allow public notes to be seen in appropriate cases. While not strictly part of this bug, it seems sensible to include it, provided my understanding of the original intentions are correct.
Finally, I didn't check all the variations of this bug, so please report back if this doesn't solve them all, and we can see what additional work needs to be done.