mahara-contributors team mailing list archive

[Aaron Wells <1538869@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This bug refers to the icons that refer next to notifications in the
user's inbox, outbox, and in the "inbox" blocktype (and possibly other
places).

Prior to Mahara 15.10, the "API" as such for this, was to look in the
theme images directory for an image with the same name as the
notification's activity type. For instance, a "feedback" notification
would use the "images/feedback.png" file.

In Mahara 15.10 these were changed to font-based icons. But rather than
specifying styles based on the notification name, there is a series of
if-then's hard-coded into every template file that displays
notifications:

- plugintype/blocktype/inbox/templates/inboxmr.tpl
- plugintype/module/multirecipientnotification/templates/activitylistin.tpl
- plugintype/module/multirecipientnotification/templates/activitylistout.tpl
- plugintype/module/multirecipientnotification/templates/activitytype.tpl
- templates/artefact/activitytype.tpl

They all share the same duplicated code:

                    {if $i->type == 'usermessage'}
                        <span class="icon icon-envelope text-default left" role="presentation" aria-hidden="true"></span>
                    {elseif $i->type == 'institutionmessage'}
                        <span class="icon icon-university text-default left" role="presentation" aria-hidden="true"></span>
                    {elseif $i->type == 'feedback'}
                        <span class="icon icon-comments text-default left" role="presentation" aria-hidden="true"></span>
                    {elseif $i->type == 'annotationfeedback'}
                        <span class="icon icon-comments-o text-default left" role="presentation" aria-hidden="true"></span>
                    {else}
                        <span class="icon icon-wrench text-default left" role="presentation" aria-hidden="true"></span>
                    {/if}

Adding a new notification type (as I recently did for Bug 547333)
requires finding & modifying every one of these files, which is a very
bug-prone process. We ought to switch this to some sort of standardized
API that will be re-used in each place. And, because new notification
types can be added by 3rd-party plugins, this API ought to support 3rd-
party plugins. Probably we'll need to do something similar to what we
did for blocktype icons, with the icon being determined by the
ActivityType class (or maybe just stored in the activity_type table).

** Affects: mahara
     Importance: Low
         Status: Confirmed


** Tags: api inbox theming

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1538869

Title:
  Need a better API for notification icons

Status in Mahara:
  Confirmed

Bug description:
  This bug refers to the icons that refer next to notifications in the
  user's inbox, outbox, and in the "inbox" blocktype (and possibly other
  places).

  Prior to Mahara 15.10, the "API" as such for this, was to look in the
  theme images directory for an image with the same name as the
  notification's activity type. For instance, a "feedback" notification
  would use the "images/feedback.png" file.

  In Mahara 15.10 these were changed to font-based icons. But rather
  than specifying styles based on the notification name, there is a
  series of if-then's hard-coded into every template file that displays
  notifications:

  - plugintype/blocktype/inbox/templates/inboxmr.tpl
  - plugintype/module/multirecipientnotification/templates/activitylistin.tpl
  - plugintype/module/multirecipientnotification/templates/activitylistout.tpl
  - plugintype/module/multirecipientnotification/templates/activitytype.tpl
  - templates/artefact/activitytype.tpl

  They all share the same duplicated code:

                      {if $i->type == 'usermessage'}
                          <span class="icon icon-envelope text-default left" role="presentation" aria-hidden="true"></span>
                      {elseif $i->type == 'institutionmessage'}
                          <span class="icon icon-university text-default left" role="presentation" aria-hidden="true"></span>
                      {elseif $i->type == 'feedback'}
                          <span class="icon icon-comments text-default left" role="presentation" aria-hidden="true"></span>
                      {elseif $i->type == 'annotationfeedback'}
                          <span class="icon icon-comments-o text-default left" role="presentation" aria-hidden="true"></span>
                      {else}
                          <span class="icon icon-wrench text-default left" role="presentation" aria-hidden="true"></span>
                      {/if}

  Adding a new notification type (as I recently did for Bug 547333)
  requires finding & modifying every one of these files, which is a very
  bug-prone process. We ought to switch this to some sort of
  standardized API that will be re-used in each place. And, because new
  notification types can be added by 3rd-party plugins, this API ought
  to support 3rd-party plugins. Probably we'll need to do something
  similar to what we did for blocktype icons, with the icon being
  determined by the ActivityType class (or maybe just stored in the
  activity_type table).

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1538869/+subscriptions