fix: Obscure notifications bell when on full view

[thevoiceofzeke]

MUMMNG-2880: "As a user dismissing/un-dismissing notifications on the notification page, I would like the bell icon to update to reflect my new unread count, so that consistency is maintained."

In this PR:

• Hide notification bell (and mobile menu count) when user is viewing the full notifications page

Why?

Because the notifications-bell (in its many forms) and view__notifications templates both use NotificationsController to establish and manipulate scope, you would think the scope would be shared among all the things that use that controller. However, this is not the case. The scope of the full view is isolated from the scope(s) of the various instances of the directive. This means that communication between them has to happen on the $rootScope level (barring yet another involved refactor of the notifications/announcements architecture). A truly syncopated experience without a prohibitive amount of work would depend upon $rootScope.$broadcast or manipulation of a $rootScope variable every time a notification is dismissed or restored, which means messily updating scope in up to 5 places every time. Additionally, the functionality of the full notifications view and the bell directive are nearly identical (a.k.a. redundant).

For the above reasons, it's simpler and arguably better practice to just hide the bell when users are already on the notifications page.

Screenshots

---

Contributor License Agreement adherence:

• This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

[vertein]

Interesting...

I would not have thought of this.

[apetro]

I suspect displaying and mutating the bell when the user takes an action affecting active notification count elsewhere would help the user to relate the bell to the action, would help the user understand these are different views on the same thing. So arguably that might be a better experience. But this solution seems nonetheless totally acceptable and reduces some aspects of the complexity to be maintained, so, +1.

[thevoiceofzeke]

Closing this pull request because it's a duplicate (and slightly behind its twin). See #572