[katello-devel] Notices generated from async tasks

[Brad Buckingham]

On 01/20/2012 09:57 AM, Bryan Kearney wrote:
> On 01/20/2012 09:51 AM, Brad Buckingham wrote:
>> On 01/20/2012 08:28 AM, Bryan Kearney wrote:
>>> On 01/20/2012 05:13 AM, Lukas Zapletal wrote:
>>>> On Thu, Jan 19, 2012 at 11:28:15PM +0100, Tomas Strachota wrote:
>>>>> 1) Determine whether a task was started from CLI or UI. Notices
>>>>> would be generated only for the UI ones. Disadvantage here is that
>>>>> if I start a task from CLI and switch to UI while it's still
>>>>> running, I won't see the result notice.
>>>>
>>>> This is really not an issue, if you started it in the CLI, you should
>>>> not see it in the UI. Period.
>>>>
>> [brad] I think there is actually a bigger question here. It is bigger
>> than this single instance of a notice on an async promotion task. Today,
>> for the UI, we have the notifications which store information about
>> various actions that an admin performs via the UI. This gives the admin
>> a bit of 'history' and perhaps could be used to support things like
>> auditing in the future (if needed). Do we have anything like that for
>> the CLI? Should we? Would an admin ever care to see what actions were
>> performed from the CLI? If not, then I'm not sure having them for the UI
>> actions is of much value either. :)
>
> IMHO.. an admin wants to see/audit what has been done. How she did it 
> is not relevant.
[brad] +1
>
>>
>> I don't think this is an issue for V1; however, I am curious if we
>> should consider some future enhancements.
>
> Yes.. post Vi.
>
>>
>> Note: if there were to be notifications generated for CLI, we could
>> 'store' them, but not display them via the UI dialog (perhaps with the
>> exception of the asynchronous ones like promotions where the user may
>> not wait for the command to complete before moving to the next command).
>
> Why not show them in the UI? Maybe not flash them, but show them in 
> the list.
[brad] Agreed.  That's what I was suggesting as well.  Store them 
(making them available in the list on the notices page), but do not 
display (flash).
>
>>>>> 2) Another option could be to pop up only notices not older than X
>>>>> minutes when you log in. Others would be marked as read
>>>>> automatically. Maybe an additional notice saying that X messages
>>>>> were skipped would be handy here.
>>>>
>>>
>>>
>>> Can we pop up the last X minutes, but still show it as unread in the
>>> background?
>>>
>> [brad] I'm not sure that I understand the question entirely. For the
>> notices, 'read' vs 'unread' is used by Katello to determine whether or
>> not the notice should be shown to the user in the form of a dialog.
>> These dialogs are displayed every 2 min (by default), when a page loads
>> or if the browser explicitly requests them. If a notice is not marked as
>> read (or viewed), it will continually be displayed at each request for
>> new notices.
>
> I see a count in the top left sometings next to admin. I assumed that 
> meant those which were not shown in a dialog
>
[brad] Today, the count shown is how many notifications are currently 
stored.  It doesn't reflect what has been viewed.  The reason being, 
when a request for new notices is sent to Katello, the response includes 
1) any notices that have not yet been viewed and 2) the current count of 
notices for the user.  With this approach, if the count represented 
notices that haven't been viewed, that number would be 0, since Katello 
just provided those that they have not seen yet.. :)

Assuming we evolve the notices to incorporate CLI (and I agree that we 
should to give the admin a clearer picture of what has happened on the 
system), we'll want to make some additional enhancements to the notices 
API and perhaps UI.  I don't view those as "big" changes though.  (e.g. 
1. Update notices api to enable generation of a notice that is stored, 
but not flashed.  2. Update UI to perhaps show the count differently 
(e.g. total vs viewed)..etc)
>>
>> The scenario that Thomas describes is to keep the user from being
>> flooded with notices upon initial login, if there were many generated by
>> CLI (or even UI). For example, show the user the last X notices (even if
>> there were X+25 generated), inform them that there are 25 additional
>> that have not been viewed and direct them to the notices pages for more
>> details.
>>> -- bk
>>>