[katello-devel] Notices generated from async tasks

Brad Buckingham bbuckingham at redhat.com
Fri Jan 20 14:51:14 UTC 2012


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. :)

I don't think this is an issue for V1; however, I am curious if we 
should consider some future enhancements.

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).
>>> 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.

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
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel




More information about the katello-devel mailing list