Ability to dismis / ok top alerts

[Jeremy Hopkins]

When alerts are displayed sitewide there is no way for a user to dismis them once they have been read.

To do this we could add an option that stores a timestamp in a custom profile field and include an "OK" button in the top alert which passed a parameter back to update this field removing the alert box.

[Info 3bits]

Do not need to modify the DB.

Just we need to add the right code to the alert: http://getbootstrap.com/javascript/#alerts

[Jeremy Hopkins]

But how do we add that to the users session, or maintain it between logins?

[Jeremy Hopkins]

Fix #179 - add setting to hide help and tools when in forums making space for forum search.

This is a poor work around and should be re-visited at some point.

→ <<cset 93e64e2c3c48>>

[Jeremy Hopkins]

Fix #179 - add setting to hide help and tools when in forums making space for forum search.

This is a poor work around and should be re-visited at some point.

→ <<cset 93e64e2c3c48>>

[Jeremy Hopkins]

Made commit against wrong issue, re-opening

[Jeremy Hopkins]

With the rewrite of the Alerts process it will be possible to add this feature. What I propose is:

• adding fields timestamps (populate with current time when setting up the alert)
• store timestamps in user preferences (where full screen / hide blocks is stored currently)
• compare timestamps in user preferences and theme settings when determining whether to dispaly alerts
• add dismiss button to alerts which sets the user preference field

The reason for using timestamps is so that alerts can be reset / re-used. If we were to use a boolean then once set for one use of the alert it could not be reused later if we had another alert to make available.

On the PHP side this will be easy and I can go ahead and add the fields / code for this. I have not looked at the bootstrap code for this or how the dismiss can be used to set the user preference field. Is that something you have experience of?

[Jeremy Hopkins]

I have added the close button to alerts but have not figured out how to use ajax to save a timestamp back to the userse preferences. We are going to need 3 timestamps if we want this to work independently for each alert type.

Looking at the full screen / hide blocks functions I can see a function in lib.php which allows ajax update:

user_preference_allow_ajax_update('theme_bcu_zoom', PARAM_TEXT);

There are related functions in custom.js.

What needs to be done is to replicate this so that for each alert close we set a timestamp into:

• theme_bcu_alert1
• theme_bcu_alert2
• theme_bcu_alert3

[Info 3bits]

I think the best way is to use the default dismiss option. We do not need to add any special code or library, just enable the dismiss alert in the code.

    <div class="alert alert-warning fade in">
        <a href="#" class="close" data-dismiss="alert">&times;</a>
        <strong>Warning!</strong> There was a problem with your network connection.
    </div>

[Jeremy Hopkins]

If you look at the current code you will see it is already using "dismiss". The issue is this does not persist, if you reload the page the alert re-appears. To make it persist we need to to get something into the session and we can do this via user preferences without any modification to the database. This is being done with the full screen / show hide blocks feature currently.

My suggestion of using a timestamp in this field is to get around the following:

1. alert is added
2. user uses dismiss and the alert disapears
3. another alert is added
4. user never sees this alert as they have already dismissed it

By using timestamps as opposed to a boolean dismiss, as new alerts are added they become visible regardless of whether a previous alert was dimsissed.

[Info 3bits]

I'm trying to find a solution using Ajax or a cookie to avoid to access the database.

[Jeremy Hopkins]

Cookies alone are not enough as we do not want the alert to re-appear if someone logs into a different pc or clears their cookies. We really need to store this somewhere for it to work properly.

User preferences will set a session variable under $USER and store the value for the user.

If you add print_r($USER); to the top of header php you will see we already store values for full screen / hide blocks in user preferences, which I am assuming is serialized or similar to create the array. Suffice to say that was done without adding any db fields.

There is a bootstrap event we maybe able to use "close.bs.alert" which fires on alert close or "closed.bs.alert" which waits for transitions to complete.

If we can hook into that and set a user preference it would work.

One other complexity would be to try and target each of the three alert boxes separately, though using timestamp we could get away with just one.

[Jeremy Hopkins]

I should have added, ajax would be needed to set the value in the background. Again if you look at the zoom full screen / show hide blocks as an example you will see ajax being used to maintain persistence of those controls.

[Info 3bits]

Ok, let's try. If not then will use a cookie. This is the only way I found that is really working in a standard site.

[Jeremy Hopkins]

Resolved by e5a1490

If you add an "alert key" into the alert settings then closing will persist. You can re-show the alert by changing this key with the message.