EBMS Tickets

This is at least a 13 for the story points, largely because it involves the Drupal message system and Drupal views. As before, we won't be affecting activity notifications created in the past. Just to be sure we're on the same page: I'm assuming we're talking about messages the system refers to as "new summary" messages, captured on the summary pages and when the reviewer uploads a summary on the review packet pages, right? The level of effort might be slightly higher for an icon than for text, but that won't be the hard part, particularly if you supply me with the icon you want us to use. If I'm wrong, we can always fall back on the text version.

Yes, that's right. And we understand this enhancement would only display for new items in the newsfeed.

Do you have an icon you'd like us to use?

I don't have an icon, but I was picturing a small yellow notepad or something along those lines. Where could I look for one?

Let me see if the creative team has something up their collective sleeves.

Posted PNG () and ICO () files.

~ZhangY41: I find Drupal's message API, which the original developers adopted for implementing the activity feed requirement of the EBMS, somewhat awkward to use, restricting what we can display in the activity feed boxes. One of the problems is that the display of the message is controlled by a single string containing embedded placeholders which are replaced at display time by the value of the fields identified by the placeholders, and there doesn't appear to be any way to add a new field and then prevent the ugly bracketed placeholder from appearing on the user's page for older messages created before the new field was added (other than manually injecting field rows in the database for the older messages, something for which there appears to be no API for doing, and which I would be reluctant to do, not knowing what such low-level tinkering of undocumented tables might break). The current pattern string for the summaries ("document activity") messages is

[message:user:name] posted [message:field_title]. [message:timestamp:custom:m/d/Y]

The only way I can think of to add the icons requested by this ticket without ugly placholders showing up for the existing messages would be to prepend the markup for the img element (floated right) when I'm populating the field_title field's value at message creation time. This would usually do exactly what we need, putting the icon in the upper right corner of the feed item. It's a kludge (because we're sticking something in a title field which isn't really a title), but I can't think of a better way to do it. I say "usually" because in an edge case in which the user name is really long, the icon could be pushed down so that it was opposite the start of the summary document's title instead of at the top of the feed item, but I don't think that's a deal breaker.

Have I missed something in my analysis? Can you think of a better technique for doing this using the Drupal Message API?

Thanks!

Well my proposed approach doesn't work, because while the pattern string does look they way I posted it in the previous message, that's not the real pattern string. The real string, which you see if you disable rich text in the Message type admin UI, is actually:

<p>[message:user:name] posted <a href="/[message:field_summary_url]">[message:field_title]</a>. [message:timestamp:custom:m/d/Y]</p>

So this poses a couple of problems. One is that my note is included in the text marked up as a clickable link for the title. As if that weren't bad enough, the message module is escaping all of the markup embedded in the field values for the messages.

Right now the best ideas I can come up with (leaving aside the radical option of rewriting the whole activity feed functionality without using the Message module) are along the lines of adding a new field with the primary key for the summary document's database row which I stick in a class or id attribute of the <p> element, and then either create some javascript which finds these and injects some additional markup inside the element, or write some PHP code which either parses the return from the $view->preview() in the document_activity() method and manipulates the DOM node, or uses regular expression manipulation to accomplish the same thing. None of these ideas are very appealing.

So ~ZhangY41: if you have any good ideas about how to solve this problem, I'm all ears. :-)

I believe I have this doing what the requirements call for. Rube Goldberg would be proud (I'm using a regular expression callback to inject the markup for the icon, using the entity ID for the message embedded in a class name for the <p> element). Ready for user testing on DEV.

Doing the modification of the message type for summary document posting notification worked fine on DEV (as far as I can tell) but doing it on QA by modifying what ebms.install does when the EBMS modules are disabled and the re-enabled during the scripted deployment (trying to follow in the footsteps of my predecessors for the Drupal message configuration) has resulted in error messages on that tier. This affects not only this ticket, but also OCEEBMS-368. I am debugging the internals of the entity module (where the failure is occurring) and will continue to do so until QA is ready for testing.

I believe I have this working. Ready for testing on QA.

While testing the new deployment technique for OCEEBMS-374 I ran into a failure for this ticket's functionality, similar to the problem with the entity API module described above, but not the same problem. This problem has only surfaced on my own clone of the EBMS STAGE site (it's not on the DEV or QA servers at NCI), so my next task is to find out why, and how to fix the problem. I'll start in on that task tomorrow morning when I'm fresh. :-)

I believe the problem I ran into last night is caused by the fact that the Linux box on which I tested is now running PHP 7, and Drupal 7 does not (yet) support PHP 7.

Confirmed the theory from the previous comment by rolling back PHP on the Linux system to PHP 5.6, which eliminated the failures.

This thread is oozing out beyond the scope of this ticket, but I want to capture the rest of what I've discovered somewhere.

I ran drush up on my test site and then I switched back to PHP 7.0. Now that the site has the current releases of the enabled modules, PHP 7.0 appears to work fine. So although I don't believe PHP 7 is officially supported for Drupal 7 yet, I don't think that when the time comes that we have to upgrade PHP (either when active support is dropped at the end of this year, or when security updates are turned off in two years) the effort will be significant. This exercise also appears to have confirmed that when we catch up with the security patches for Drupal core and our enabled modules, we'll probably survive without too much scrambling (I didn't see any breakage in my admittedly superficial testing).

Verified on QA.

Verified in Board Manager Document Activity Feed. (Haven't tested Board Member feed. Will reopen if there are issues in that feed.)