Message Center for the Public Catalog

Bug #1410369 reported by Jason Etheridge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

Currently, Evergreen does not provide a way for libraries to push messages to patrons in a way that can be accessed from their account page in the public catalog. This project will create a system for "user messages" that exist separately from notes and penalties, but can be generated from notes and from A/T events. I'll attach full tech specs this week, but wanted to get this in before the 2.8 Feature Target deadline.

Patron messages will be generated by the following events:

* creation of a new “public” patron note
* changing the visibility of an existing patron note from staff to “public”
* creation of an action/trigger event, provided that the event definition has a patron message template defined

Patrons will be able to read messages from the account overview page when logged in to the OPAC, and will be able to mark messages as read or unread or delete them.

Library staff members will also have access to the list of messages sent to each patron.

Changed in evergreen:
assignee: nobody → Jason Etheridge (phasefx)
milestone: none → 2.8-beta
Revision history for this message
Jason Etheridge (phasefx) wrote :
Galen Charlton (gmc)
Changed in evergreen:
importance: Undecided → Wishlist
Revision history for this message
Galen Charlton (gmc) wrote :

The collab/gmcharlt/lp1410369_message_center branch in the working repository contains the completed feature:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/lp1410369_message_center

Some test scenarios to try:

- entering a new, public user note via the staff client, then verifying that a new message shows in in the TPAC my account page
- activating the new stock hold cancellation A/T events, creating a hold, canceling it (or letting it shelf-expire), then verifying that A/T generates a new message
- interacting with messages while logged into TPAC, including verifying that messages can be read, marked as unread, and deleted.

tags: added: pullrequest
Galen Charlton (gmc)
Changed in evergreen:
assignee: Jason Etheridge (phasefx) → nobody
Revision history for this message
Bill Erickson (berick) wrote :

Hi, I've encountered an issue in my testing. Using PCRUD within the TPAC to retrieve a user's messages requires the user in question to have the 'VIEW_USER' permission. This will not be the case for most patrons, of course. I believe this will require a dedicated middle-layer API so the messages can be accessed directly via cstore.

The code in question is Account::__fetch_user_messages()

Revision history for this message
Mike Rylander (mrylander) wrote :

That seems odd -- the owning_user attribute on the permacrud->actions->[retreive|update|delete] elements should bypass that need. Any debug output from pcrud available? Am I imagining that that part of 1254918 made it into master? My source says no (line 7531 of Open-ILS/src/c-apps/oils_sql.c), but ...

Revision history for this message
Mike Rylander (mrylander) wrote :

Galen pointed out the reason ... we ignore the owning user if there's a context org. That ... is wrong. The original bug's description is not perfectly clear on that point, and I can't find a reason that owning_user should not be honored in all cases where it is set in the IDL. If anyone /can/ think of a reason, please say so -- we can adjust this with object permissions. Adjustment to the pcrud owning_user stuff coming soon...

Revision history for this message
Bill Erickson (berick) wrote :

Aha, I had forgotten about owning_user. Agreed it should be honored in all cases.

Revision history for this message
Mike Rylander (mrylander) wrote :

I've pushed a change to have PCRUD always respect the owning_user IDL field. I still can't see a reason not to...

Same branch, top commit. (git-diff -b shows the real changes, mostly whitespace)

Thanks for testing, Bill!

Revision history for this message
Galen Charlton (gmc) wrote :

I've pushed two more patches to the branch:

- a new, limited-purpose view so that patrons cannot directly edit the text of their messages
- release notes

Revision history for this message
Bill Erickson (berick) wrote :

All messages now display in the TPAC, yay!

Moving on to more tests.. I am unable to generate a message from an action_trigger event, specifically testing event_def 52 "Hold Cancelled (Staff) User Message". The event is created and appears to process without error, but the usr_message never materializes.

I added some debug logs to Event.pm and found that w/ the stock def, we get into this code block:

if ($self->event->event_def->message_usr_path and $self->environment->{usr_message}{template}) {
...
}

But we don't get into this code block:

if ($env->{usr_message}{usr} && $env->{usr_message}{template}) {
}

As an experiment, I set the "group_field" to null on the event def, thinking it might be having problems finding the user field, and then the code did make it into the above code block. However, the next step then produces no output:

my $message_template_output =
    $reactor->pass('ProcessMessage')->run->final_result;

That's as far as I could get at the time. Hope this helps.

Revision history for this message
Mike Rylander (mrylander) wrote : Re: [Bug 1410369] Re: Message Center for the Public Catalog

Ah! I can fix that. not at a computer right now, but it's clear to me now.
Thanks.

--miker

On Thu, Feb 19, 2015, 6:11 PM Bill Erickson <email address hidden> wrote:

> All messages now display in the TPAC, yay!
>
> Moving on to more tests.. I am unable to generate a message from an
> action_trigger event, specifically testing event_def 52 "Hold Cancelled
> (Staff) User Message". The event is created and appears to process
> without error, but the usr_message never materializes.
>
> I added some debug logs to Event.pm and found that w/ the stock def, we
> get into this code block:
>
> if ($self->event->event_def->message_usr_path and
> $self->environment->{usr_message}{template}) {
> ...
> }
>
> But we don't get into this code block:
>
> if ($env->{usr_message}{usr} && $env->{usr_message}{template}) {
> }
>
> As an experiment, I set the "group_field" to null on the event def,
> thinking it might be having problems finding the user field, and then
> the code did make it into the above code block. However, the next step
> then produces no output:
>
> my $message_template_output =
> $reactor->pass('ProcessMessage')->run->final_result;
>
> That's as far as I could get at the time. Hope this helps.
>
> --
> You received this bug notification because you are a member of Evergreen
> Bug Wranglers, which is subscribed to Evergreen.
> https://bugs.launchpad.net/bugs/1410369
>
> Title:
> Message Center for the Public Catalog
>
> Status in Evergreen - Open ILS:
> New
>
> Bug description:
> Currently, Evergreen does not provide a way for libraries to push
> messages to patrons in a way that can be accessed from their account
> page in the public catalog. This project will create a system for
> "user messages" that exist separately from notes and penalties, but
> can be generated from notes and from A/T events. I'll attach full
> tech specs this week, but wanted to get this in before the 2.8 Feature
> Target deadline.
>
> Patron messages will be generated by the following events:
>
> * creation of a new “public” patron note
> * changing the visibility of an existing patron note from staff to
> “public”
> * creation of an action/trigger event, provided that the event
> definition has a patron message template defined
>
> Patrons will be able to read messages from the account overview page
> when logged in to the OPAC, and will be able to mark messages as read
> or unread or delete them.
>
> Library staff members will also have access to the list of messages
> sent to each patron.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1410369/+subscriptions
>

Revision history for this message
Galen Charlton (gmc) wrote :

Mike and I have pushed patches to fix the issues with updating the A/T environment, as well as a thinko in the auml IDL change. It's ready for testing again.

Revision history for this message
Kathy Lussier (klussier) wrote :
tags: added: signedoff
Revision history for this message
Bill Erickson (berick) wrote :

Pushed to master. Thanks, everyone!

Changed in evergreen:
status: New → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.