incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Brondsema" <>
Subject [allura:tickets] #6777 Create a site-wide notification mechanism
Date Mon, 21 Oct 2013 20:43:26 GMT
The mongo index should be on (deleted, _id) for the current() query to be fastest.  And since
this will run on every pageview, we need it to be very fast.

Setting a cookie for each notification's impression count and also when it's been closed seems
excessive.  That could add up to a lot of cookies.  We could have just one cookie per notification.
 Or probably better would be to store it on user session which is persisted as just a single
cookie.  And we can keep that small by popping off the old notifications' data.  One problem:
closing a notification is done all client-side in this implementation.  We'd have to make
an AJAX call if we stored it in the session.  Hybrid could be a cookie for closed notification
and impressions stored on the session.  Or, assuming we have only one current notification,
we could do it all with cookies but just one or two, using the same cookie name all the time
and just updating the value to match the current notification id.

Since there's no obvious administration mechanism for this, we should add to docs/administration.rst
explaining how to manually create a notification entry.


** [tickets:#6777] Create a site-wide notification mechanism**

**Status:** in-progress
**Created:** Fri Oct 18, 2013 09:37 PM UTC by Cory Johns
**Last Updated:** Mon Oct 21, 2013 08:04 PM UTC
**Owner:** Cory Johns

It's sometimes useful to present some information to all users in a semi-persistent fashion,
related to the site as a whole.  Create a mechanism to store and present these notifications.

The notifications should be semi-persistent, unlike the existing flash messages.  The notifications
should be closable; once closed, they should not show up for that user again until a new message
is in effect.  The notifications should also support a (per message?) configurable number
of impressions per user; after the user has seen the message the specified number of times,
it should no longer be shown to that user.


Sent from because is subscribed to

To unsubscribe from further messages, a project admin can change settings at
 Or, if this is a mailing list, you can unsubscribe from the mailing list.
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message