EBMS Tickets

This is trickier than we thought when we first estimated the work for this task, We don't have the information we need to support the request, and there are about a half-dozen different message types, each one of which will need separate customization. The fact that we're using a third-party module (message) instead of code we wrote ourselves makes it harder to figure out how this customization will be done. I started bumping up the story points to 20, thinking we'd need different links for new packets, depending on whether the current user is a board member or a board manager (or some other role), but I believe I have determined that only board members are notified about new packets, so I'm reducing the estimate to 13. If my assumption that no message types will need different URLs based on the role of the currently logged-in user, 20 may not even be high enough.

What should the link bring up for notifications about "New ... articles posted"? In fact, could you please specify where the link should go for each of the notification types you want modified?

Thanks.

I posted a document listing each of the notifications and where their links should go.

Unless I'm missing something, the comments in the code don't match what the code is actually doing for event notifications. Here's what the comment says:

        // if the node is published and either is new or was previously
        // unpublished, note the publish activity

But the code isn't actually looking at the Published flag (set or turned off at the bottom of the event editing form) but is instead comparing the previous version of the Event Status field (set at the top of the event editing form with a value of "On Calendar" or "Cancelled"). So my questions are:

1. What's the relationship between these two fields (Event Status and Published)?

2. What would it mean for an event to be "Unpublished" and "On Calendar"?

3. Is the Published flag always ignored by the users (if so, that might explain why the code ignores its previous value when it's deciding whether to create a notification for an existing event, though I would have expected a comment somewhere to that effect in the code if that were the explanation)?

Another question about the existing behavior: is it a mistake that for a brand new event with a published agenda you get two notifications, one for the event and the second for the publication of the agenda, or was that what the requirements asked for? And what you really want? (Which is not necessarily the same thing, so I've snuck in a second question.)

I'll take the last question first. It is correct that there are two notifications for a new event and the publication of the agenda for an event. The events are typically added far in advance; agendas are added closer to the meeting. So, both notifications are appropriate.

As for the published flag on an event - we adjust the flag rarely but we do use it. It's typically taken off (made "unpublished") if we add a calendar event by mistake or we think it would be confusing to have the event display on the calendar. Cancelling an event (but keeping it published) keeps the event on the calendar but grays it out, so that is more commonly what we do. I could see us creating a calendar event and quickly deleting it, but retaining the "on calendar" status since it doesn't show up anyway.

Implemented on DEV. We were way too low on our LOE estimate for this one.

Thank you, Bob! I noticed a few things on DEV:

Links from FYI packets and Completed packets in the literature activity feed are bringing me to the top of the Assigned Packets page. Could these instead bring me to the particular packet (listed on the FYI packets page or the Completed packets page)?

The document activity feed is not currently showing the name of the document on DEV. Instead, it says "[message:field_title]". For example:

Test Board Member posted [message:field_title]. 10/28/2015

Also related to the document notifications, rather than link to the appropriate summaries subpage, could the link from the just open up the document? We realized this would save us some steps.

I confirmed that the published flag is unchecked VERY rarely, so this is not a concern.

I noticed one other thing on DEV:

The link from the "articles posted" notification should point to the REVIEW CITATIONS page, not the REVIEWED PACKETS page, as it is pointing to now. For Admin Assistants (who also see this notification), the link should go to the FULL TEXT RETRIEVAL page, if possible.

The "articles posted" notifications are created when the articles are moved into the "Published" state. Yes, eventually some of them will get to the subsequent state in which they're ready for retrieval of the PDF for the full text of the article, but that doesn't happen right away. So I'm a little unclear about how it's going to work to send the user to the Full Text Retrieval page.

I think I've got everything done that needs to be. See previous comment about the inappropriateness of linking to the full text retrieval page. Testing needs to be done with newly-created notifications (the existing ones won't necessarily have the new information needed for these enhancements).

I agree that linking to the Full Text Retrieval page isn't an exact match for this notification, but the reason Bonnie sees these notifications is so she is aware that citations have been published to the Board manager queues and will soon be landing in her Full Text Retrieval queue, so that's why I was suggesting that we bring her to her queue page. I am checking with the other Board managers and Bonnie as to what they all feel would be a reasonable link here, or if it should not link to anything for the admin assistant role.

I talked with the other Board managers and with Bonnie and we decided that it really doesn't matter what this points to for the Admin Assistant role. Could we just remove the link from her literature activity feed? Or, if it's simpler to keep it at is, that's okay too. Thanks.

We decided to leave the Admin Assistant link the way it is and it won't be used.

The links from the Literature Activity feed to assigned packets are not working.

For example, I just posted two Genetics of Skin Cancer packets and logged in as Test Board Member 3. The link to each of the packets results in the following error message:

You have requested a page which does not exist.

Fixed on DEV and QA; please try again.

Verified on QA.

Verified on PROD.