Add Notification history feature in order to provide proper notifications with names of mutated resources

[gildub]

Historically, we had (and still have) a created object's name displayed in the success (or failure) notification.
This was very straightforward because the REST POST function returns the entire object including its name.

That didn't happen when editing an object.
The main reason is because the HUB API's PUT requests do not return the object details when successful.

So to include the name in the notification we have to cater for the case and pass the object (or it's name) to the query so we pass it along for later notifications.
Or alternatively we could ask the HUB to provide the saved object in its response (as you know RESTFUL is not a hard standard but that seems to be a good practice for PUT to respond with the object.)
Either way, this is not a difficult constraint but more a impact choice.

To take such decision, we have to evaluate the need to generalize the notification of an object name after editing the resource.

First, let's note that so far we don't provide that even for the applications (which represents one of our key resource).
We have to be careful here not to create a precedent because otherwise that could become a de-facto requirement.

Correct if wrong here, but it seems there are no actual requirements asking to display the name of the object being saved in the notifications (being either after a success or failure).

In which case we have to provide the best answer for the use experience and ask ourselves:
How helpful is it to display the name of a modified resource in the notifications messages ?

On one side we could say "it's overkill" because the notification is so brief then one barely have time to read it (and itś worsen when the object name is long and as the notification phrase grows).

From an ergonomic viewpoint, if the user missed the notification, then only the short term memory is to help recall if the notification was [GREEN] or [RED] (Green doesn't necessarily means it was ok - see below).
Unfortunately the notifications component doesn't provide history of the notifications and we cannot expect the user to start digging in console.log to work around it.

One could also argue the user knows what object it's modifying so knowing the modification has been accepted could be enough.

On the other side, providing a feedback to the user with the name of the modified object can help confirm or not that's the one the user expected to change. Thinking here about the green case above which means not ok: "Darned, I modified the wrong object !!!"

There might be other pros and cons (input please!).

But from what we already have here, I'd say it would make sense to have a more advance notification solution prior of thinking about generalizing the name of mutated objects in the notifications.

A similar question applies for object deletion (thus I used mutated in the title).
Note we already have 3 resources involved with the notification informing the user of the deleted object's name.
I'm the one to blame as I started first (about 3 months ago) with the MigrationWavs and then later with the Trackers.
And @ibolton336 used it with the Identities.
So here we have a precedent which we need to address and decide as well if we must generalize it or not.
And generalizing it makes sense once we have notification history.

What do you think ?

[gildub]

Well, it sounds obvious now that using PF Notification drawer would be a way to go.

If we agree with such approach then I'll be happy to work on it.