UI notifications

Hi,

I'm working on adding async notifications to foreman UI, where it
would be possible to show events, even if you didnt refresh the page
etc.

I'm trying to figure out which kind of notifications would make sense,
so far I could think of the following:

  • long running tasks (e.g. when machines finish provisioning?)
  • import failures (e.g. 500 ERRORS) that are generated by the API
    (such as fact/enc/reports query)

Another side, is to save failures, e.g. right now, if there is an
error (e.g. 500 error from a proxy) it gets logged, but not visible
in the UI, would it make sense to keep that errors until ack
somewhere?

so in general, which kind of information did you find lacking, and had
to start searching logs or other places where its obvious foreman
could display it?

thanks!
Ohad

In comparing katello notices to foreman audits, I really like the foreman audits because they tend to answer an admin's questions: "What happened in the past day, by whom, and what changed?"

The missing piece of audits is that they currently log only successful changes. If they could be augmented to show failures as well, that would be very helpful.

"User 'joey' failed to login" <-- repeated 200 times implies some sort of unauthorized access attemp
"Scheduled sync of repo 'RHEL' to 'Library'" <-- needs immediate attention
"User 'joey' failed to create new user 'bob': Permission denied" <-- who is this joey and what is he up to?

Katello's notices tend towards things that are not nearly as useful for auditing.

"Creating activation key requires content view" <-- an interactive notice and not interesting beyond immediate display on screen

If the new notices system could include a way to signal that some notices need to land in the audit logs too, that would be great.

··· ----- Original Message ----- > From: "Ohad Levy" > To: "foreman-dev" > Sent: Saturday, November 23, 2013 3:28:25 PM > Subject: [foreman-dev] UI notifications > > Hi, > > I'm working on adding async notifications to foreman UI, where it > would be possible to show events, even if you didnt refresh the page > etc. > > I'm trying to figure out which kind of notifications would make sense, > so far I could think of the following: > > * long running tasks (e.g. when machines finish provisioning?) > * import failures (e.g. 500 ERRORS) that are generated by the API > (such as fact/enc/reports query) > > Another side, is to save failures, e.g. right now, if there is an > error (e.g. 500 error from a proxy) it gets logged, but not visible > in the UI, would it make sense to keep that errors until ack > somewhere? > > so in general, which kind of information did you find lacking, and had > to start searching logs or other places where its obvious foreman > could display it? > > thanks! > Ohad > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

>
>
>> From: "Ohad Levy" <ohadlevy@gmail.com>
>> To: "foreman-dev" <foreman-dev@googlegroups.com>
>> Sent: Saturday, November 23, 2013 3:28:25 PM
>> Subject: [foreman-dev] UI notifications
>>
>> Hi,
>>
>> I'm working on adding async notifications to foreman UI, where it
>> would be possible to show events, even if you didnt refresh the page
>> etc.
>>
>> I'm trying to figure out which kind of notifications would make sense,
>> so far I could think of the following:
>>
>> * long running tasks (e.g. when machines finish provisioning?)
>> * import failures (e.g. 500 ERRORS) that are generated by the API
>> (such as fact/enc/reports query)
>>
>> Another side, is to save failures, e.g. right now, if there is an
>> error (e.g. 500 error from a proxy) it gets logged, but not visible
>> in the UI, would it make sense to keep that errors until ack
>> somewhere?
>>
>> so in general, which kind of information did you find lacking, and had
>> to start searching logs or other places where its obvious foreman
>> could display it?
>>
>> thanks!
>> Ohad
>>
>> –
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> In comparing katello notices to foreman audits, I really like the foreman audits because they tend to answer an admin's questions: "What happened in the past day, by whom, and what changed?"

+1

I like the audit view.

In Spacewalk/Satellite for example, it's only possible for very few actions to find out who did what and when.

>
> The missing piece of audits is that they currently log only successful changes. If they could be augmented to show failures as well, that would be very helpful.

And pending tasks (like host building?), maybe.

I like VMware's way of showing status (at the bottom):
http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png

You always have an idea of what's going on.

If something deserves a notice to the user, doesn't it deserve to be audited? It seems like audits and notices could be one thing. Urgent user facing issues get :display => true or something.

··· On Nov 24, 2013, at 3:50 PM, Tom McKay wrote: > ----- Original Message -----


Stephen Benjamin
stephen@bitbin.de

> From: "Stephen Benjamin" <stephen@bitbin.de>
> To: foreman-dev@googlegroups.com
> Sent: Sunday, November 24, 2013 11:58:29 AM
> Subject: Re: [foreman-dev] UI notifications
>
>
> >
> >
> >> From: "Ohad Levy" <ohadlevy@gmail.com>
> >> To: "foreman-dev" <foreman-dev@googlegroups.com>
> >> Sent: Saturday, November 23, 2013 3:28:25 PM
> >> Subject: [foreman-dev] UI notifications
> >>
> >> Hi,
> >>
> >> I'm working on adding async notifications to foreman UI, where it
> >> would be possible to show events, even if you didnt refresh the page
> >> etc.
> >>
> >> I'm trying to figure out which kind of notifications would make sense,
> >> so far I could think of the following:
> >>
> >> * long running tasks (e.g. when machines finish provisioning?)
> >> * import failures (e.g. 500 ERRORS) that are generated by the API
> >> (such as fact/enc/reports query)
> >>
> >> Another side, is to save failures, e.g. right now, if there is an
> >> error (e.g. 500 error from a proxy) it gets logged, but not visible
> >> in the UI, would it make sense to keep that errors until ack
> >> somewhere?
> >>
> >> so in general, which kind of information did you find lacking, and had
> >> to start searching logs or other places where its obvious foreman
> >> could display it?
> >>
> >> thanks!
> >> Ohad
> >>
> >> –
> >> You received this message because you are subscribed to the Google Groups
> >> "foreman-dev" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to foreman-dev+unsubscribe@googlegroups.com.
> >> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >
> > In comparing katello notices to foreman audits, I really like the foreman
> > audits because they tend to answer an admin's questions: "What happened in
> > the past day, by whom, and what changed?"
>
> +1
>
> I like the audit view.
>
> In Spacewalk/Satellite for example, it's only possible for very few actions
> to find out who did what and when.
>
> >
> > The missing piece of audits is that they currently log only successful
> > changes. If they could be augmented to show failures as well, that would
> > be very helpful.
>
> And pending tasks (like host building?), maybe.
>
> I like VMware's way of showing status (at the bottom):
> http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png
>
> You always have an idea of what's going on.

That's a nice UI view: Slide up and then slide down to hide right on the page. Would let me monitor tasks while going about other admin chores.

>
> If something deserves a notice to the user, doesn't it deserve to be audited?
> It seems like audits and notices could be one thing. Urgent user facing
> issues get :display => true or something.

Agreed. Some sort of user pref on a per-audit basis to trigger popping a notice or not. "Argh! Bob from accounting is having trouble logging in again… Better set failed login audits to pop so I can remind him his password was reset from 1234."

··· ----- Original Message ----- > On Nov 24, 2013, at 3:50 PM, Tom McKay wrote: > > ----- Original Message -----


Stephen Benjamin
stephen@bitbin.de

>
>
> > From: "Stephen Benjamin" <stephen@bitbin.de>
> > To: foreman-dev@googlegroups.com
> > Sent: Sunday, November 24, 2013 11:58:29 AM
> > Subject: Re: [foreman-dev] UI notifications
> >
> >
> > >
> > >
> > >> From: "Ohad Levy" <ohadlevy@gmail.com>
> > >> To: "foreman-dev" <foreman-dev@googlegroups.com>
> > >> Sent: Saturday, November 23, 2013 3:28:25 PM
> > >> Subject: [foreman-dev] UI notifications
> > >>
> > >> Hi,
> > >>
> > >> I'm working on adding async notifications to foreman UI, where it
> > >> would be possible to show events, even if you didnt refresh the page
> > >> etc.
> > >>
> > >> I'm trying to figure out which kind of notifications would make sense,
> > >> so far I could think of the following:
> > >>
> > >> * long running tasks (e.g. when machines finish provisioning?)
> > >> * import failures (e.g. 500 ERRORS) that are generated by the API
> > >> (such as fact/enc/reports query)
> > >>
> > >> Another side, is to save failures, e.g. right now, if there is an
> > >> error (e.g. 500 error from a proxy) it gets logged, but not visible
> > >> in the UI, would it make sense to keep that errors until ack
> > >> somewhere?
> > >>
> > >> so in general, which kind of information did you find lacking, and had
> > >> to start searching logs or other places where its obvious foreman
> > >> could display it?
> > >>
> > >> thanks!
> > >> Ohad
> > >>
> > >> –
> > >> You received this message because you are subscribed to the Google
> > >> Groups
> > >> "foreman-dev" group.
> > >> To unsubscribe from this group and stop receiving emails from it, send
> > >> an
> > >> email to foreman-dev+unsubscribe@googlegroups.com.
> > >> For more options, visit https://groups.google.com/groups/opt_out.
> > >>
> > >
> > > In comparing katello notices to foreman audits, I really like the foreman
> > > audits because they tend to answer an admin's questions: "What happened
> > > in
> > > the past day, by whom, and what changed?"
> >
> > +1
> >
> > I like the audit view.
> >
> > In Spacewalk/Satellite for example, it's only possible for very few actions
> > to find out who did what and when.
> >
> > >
> > > The missing piece of audits is that they currently log only successful
> > > changes. If they could be augmented to show failures as well, that would
> > > be very helpful.
> >
> > And pending tasks (like host building?), maybe.
> >
> > I like VMware's way of showing status (at the bottom):
> > http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png
> >
> > You always have an idea of what's going on.
>
> That's a nice UI view: Slide up and then slide down to hide right on the
> page. Would let me monitor tasks while going about other admin chores.
>
> >
> > If something deserves a notice to the user, doesn't it deserve to be
> > audited?
> > It seems like audits and notices could be one thing. Urgent user facing
> > issues get :display => true or something.
>
> Agreed. Some sort of user pref on a per-audit basis to trigger popping a
> notice or not. "Argh! Bob from accounting is having trouble logging in
> again… Better set failed login audits to pop so I can remind him his
> password was reset from 1234."

FYI: I'm working on the task statuses rework in Katello right now with improved
realtime reporting and auditing features. I will demo the work so far on today
Katello sprint demo (I can give a deep dive later on as well). Ohad: I really
recommand you to take a loot at that.

About the audit, I agree that it has a lot in common with user notifications.
What we do right now is showing the user the recent actions he triggered on resources.
We don't include however attempts that failed on model validations, as nothing
was really affected from the resource point of view.

How it works: every modification action will have a task record created (we
use dynflow for that). The task is used for both short running actions
(performing actions only locally in database) or distributed actions
(perofrming rest calls to tother services). The task is assigned to
every resource that is connected to that task somehow: there are more task -> resource relations:

  • locks: when repository is being synced, we don't want to allow other actions to be performed on that resource
  • links: the product that contains the repository is linked to the task as well: this allows us to include
    the repository sync task in list of tasks under the product, the same mechanism gets
    the task into the tasks of the organization.

Every task also holds all the information needed for auditing, the data about the resource it was run
on top of and the user that triggered it. This allows us to show the details of the task even
when the resource, that task was on, is deleted.

With this approach, we are also able very easily produce cli examples for the tasks.

So for example, when I run repository synchronization, it shows up in the repository tasks,
product tasks, provider tasks and organization tasks. Even when I delete the provider, I will
still see the information about the action in organization tasks.

It would be probably worth doing a deep-dive on that.

– Ivan

··· ----- Original Message ----- > ----- Original Message ----- > > On Nov 24, 2013, at 3:50 PM, Tom McKay wrote: > > > ----- Original Message -----


Stephen Benjamin
stephen@bitbin.de


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

I think we shouldn't confuse audit logging and UI notifications by trying
to build them into the same feature. For me, user initiated (or scheduled
actions) that result in a success or error should provide a visible
notification by default to the user. Auditing should be first and foremost
focused on providing a history and trail of actions that people with the
right permissions can view or export. An audit could generate a
notification, but a notification should be dismissible/removable/deletable
while an audit should remain indefinitely (or until some organizational
policy specifies when to clean out old audits).

Types:

  • Long running tasks
  • Scheduled tasks
  • System and backend system failures

Interaction:

  • Success notices should not intrude on the user (i.e. no top level flash
    notifications that block the header)
  • Error messages should be apparent to the user but not force them to deal
    with them if in the middle of working on something (i.e. error notices that
    show up visibly in the UI but do not block any portion of it)
  • +1 for being able to subscribe to notifications but this could be a
    future refinement

-Eric

··· On Mon, Nov 25, 2013 at 3:36 AM, Ivan Necas wrote:

----- Original Message -----

----- Original Message -----

From: “Stephen Benjamin” stephen@bitbin.de
To: foreman-dev@googlegroups.com
Sent: Sunday, November 24, 2013 11:58:29 AM
Subject: Re: [foreman-dev] UI notifications

On Nov 24, 2013, at 3:50 PM, Tom McKay thomasmckay@redhat.com wrote:

----- Original Message -----

From: “Ohad Levy” ohadlevy@gmail.com
To: “foreman-dev” foreman-dev@googlegroups.com
Sent: Saturday, November 23, 2013 3:28:25 PM
Subject: [foreman-dev] UI notifications

Hi,

I’m working on adding async notifications to foreman UI, where it
would be possible to show events, even if you didnt refresh the page
etc.

I’m trying to figure out which kind of notifications would make
sense,

so far I could think of the following:

  • long running tasks (e.g. when machines finish provisioning?)
  • import failures (e.g. 500 ERRORS) that are generated by the API
    (such as fact/enc/reports query)

Another side, is to save failures, e.g. right now, if there is an
error (e.g. 500 error from a proxy) it gets logged, but not visible
in the UI, would it make sense to keep that errors until ack
somewhere?

so in general, which kind of information did you find lacking, and
had

to start searching logs or other places where its obvious foreman
could display it?

thanks!
Ohad


You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

In comparing katello notices to foreman audits, I really like the
foreman

audits because they tend to answer an admin’s questions: "What
happened

in
the past day, by whom, and what changed?"

+1

I like the audit view.

In Spacewalk/Satellite for example, it’s only possible for very few
actions

to find out who did what and when.

The missing piece of audits is that they currently log only
successful

changes. If they could be augmented to show failures as well, that
would

be very helpful.

And pending tasks (like host building?), maybe.

I like VMware’s way of showing status (at the bottom):

http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png

You always have an idea of what’s going on.

That’s a nice UI view: Slide up and then slide down to hide right on the
page. Would let me monitor tasks while going about other admin chores.

If something deserves a notice to the user, doesn’t it deserve to be
audited?
It seems like audits and notices could be one thing. Urgent user
facing

issues get :display => true or something.

Agreed. Some sort of user pref on a per-audit basis to trigger popping a
notice or not. “Argh! Bob from accounting is having trouble logging in
again… Better set failed login audits to pop so I can remind him his
password was reset from 1234.”

FYI: I’m working on the task statuses rework in Katello right now with
improved
realtime reporting and auditing features. I will demo the work so far on
today
Katello sprint demo (I can give a deep dive later on as well). Ohad: I
really
recommand you to take a loot at that.

About the audit, I agree that it has a lot in common with user
notifications.
What we do right now is showing the user the recent actions he triggered
on resources.
We don’t include however attempts that failed on model validations, as
nothing
was really affected from the resource point of view.

How it works: every modification action will have a task record created (we
use dynflow for that). The task is used for both short running actions
(performing actions only locally in database) or distributed actions
(perofrming rest calls to tother services). The task is assigned to
every resource that is connected to that task somehow: there are more task
-> resource relations:

  • locks: when repository is being synced, we don’t want to allow other
    actions to be performed on that resource
  • links: the product that contains the repository is linked to the task
    as well: this allows us to include
    the repository sync task in list of tasks under the product, the same
    mechanism gets
    the task into the tasks of the organization.

Every task also holds all the information needed for auditing, the data
about the resource it was run
on top of and the user that triggered it. This allows us to show the
details of the task even
when the resource, that task was on, is deleted.

With this approach, we are also able very easily produce cli examples for
the tasks.

So for example, when I run repository synchronization, it shows up in the
repository tasks,
product tasks, provider tasks and organization tasks. Even when I delete
the provider, I will
still see the information about the action in organization tasks.

It would be probably worth doing a deep-dive on that.

– Ivan


Stephen Benjamin
stephen@bitbin.de


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

> I think we shouldn't confuse audit logging and UI notifications by
> trying to build them into the same feature. For me, user initiated (or
> scheduled actions) that result in a success or error should provide a
> visible notification by default to the user. Auditing should be first
> and foremost focused on providing a history and trail of actions that
> people with the right permissions can view or export. An audit could
> generate a notification, but a notification should be
> dismissible/removable/deletable while an audit should remain
> indefinitely (or until some organizational policy specifies when to
> clean out old audits).
>

I agree that it's not the same thing, but I think that notifications
should be built upon doable actions and since Dynflow will provide a
list of all actions which user can take in the application I would use that.

As Ivan mentioned in the demo. They are/will be top-level actions
defined to represent each action which user can take in the application
modifying any resource.

There is a single point of entry to triggering these actions. it looks
something like following:

Actions.trigger(::Actions::Katello::Repository::Sync, @repository)

It could be enriched with API for notifications so a developer would be
able to say for what actions and on which conditions he wishes to show a
notification to a user based on where the action is triggered. I think
following behavior would make sense.

Let Actions::Katello::Repository::Sync be Sync.

Sync = Actions::Katello::Repository::Sync

In all API controllers

Actions.trigger(Sync, @repository, notify: false)

In all UI controllers depending on situation

Long running tasks

Actions.trigger(Sync, @repository, notify: true)

scheduled tasks

Actions.trigger(Sync, @repository, notify: :on_failure)

Note: Actions is not a part of Dynflow it's a thin wrapper specific for
Katello to access Dynflow's World. It can be easily extended as needed.

This has an advantage that Notification can be represented only as
following simple model:

User 1-N Notification N-1 AuditEntry

Where Notification would only have FKs and flag if user saw the
notification and AuditEntry is simplified representation, it is a link
to Dynflow's ExecutionPlan instance in real implementation.

Note: It would also probably make sense to mark some notification as
auto-delete, to be removed after they are seen by user. Possible all
success notification could be auto-deleted, failures would stick.

··· On 25.11.13 17:52, Eric D Helms wrote:

Types:

  • Long running tasks
  • Scheduled tasks
  • System and backend system failures

Interaction:

  • Success notices should not intrude on the user (i.e. no top level
    flash notifications that block the header)
  • Error messages should be apparent to the user but not force them to
    deal with them if in the middle of working on something (i.e. error
    notices that show up visibly in the UI but do not block any portion of it)
  • +1 for being able to subscribe to notifications but this could be a
    future refinement

-Eric

On Mon, Nov 25, 2013 at 3:36 AM, Ivan Necas <inecas@redhat.com > mailto:inecas@redhat.com> wrote:

----- Original Message -----
 >
 >
 > ----- Original Message -----
 > > From: "Stephen Benjamin" <stephen@bitbin.de
<mailto:stephen@bitbin.de>>
 > > To: foreman-dev@googlegroups.com
<mailto:foreman-dev@googlegroups.com>
 > > Sent: Sunday, November 24, 2013 11:58:29 AM
 > > Subject: Re: [foreman-dev] UI notifications
 > >
 > > On Nov 24, 2013, at 3:50 PM, Tom McKay <thomasmckay@redhat.com >     <mailto:thomasmckay@redhat.com>> wrote:
 > >
 > > >
 > > >
 > > > ----- Original Message -----
 > > >> From: "Ohad Levy" <ohadlevy@gmail.com
<mailto:ohadlevy@gmail.com>>
 > > >> To: "foreman-dev" <foreman-dev@googlegroups.com
<mailto:foreman-dev@googlegroups.com>>
 > > >> Sent: Saturday, November 23, 2013 3:28:25 PM
 > > >> Subject: [foreman-dev] UI notifications
 > > >>
 > > >> Hi,
 > > >>
 > > >> I'm working on adding async notifications to foreman UI,
where it
 > > >> would be possible to show events, even if you didnt refresh
the page
 > > >> etc.
 > > >>
 > > >> I'm trying to figure out which kind of notifications would
make sense,
 > > >> so far I could think of the following:
 > > >>
 > > >> * long running tasks (e.g. when machines finish provisioning?)
 > > >> * import failures (e.g. 500 ERRORS) that are generated by
the API
 > > >> (such as fact/enc/reports query)
 > > >>
 > > >> Another side, is to save failures, e.g. right now, if there
is an
 > > >> error  (e.g. 500 error from a proxy) it gets logged, but not
visible
 > > >> in the UI, would it make sense to keep that errors until ack
 > > >> somewhere?
 > > >>
 > > >> so in general, which kind of information did you find
lacking, and had
 > > >> to start searching logs or other places where its obvious
foreman
 > > >> could display it?
 > > >>
 > > >> thanks!
 > > >> Ohad
 > > >>
 > > >> --
 > > >> You received this message because you are subscribed to the
Google
 > > >> Groups
 > > >> "foreman-dev" group.
 > > >> To unsubscribe from this group and stop receiving emails
from it, send
 > > >> an
 > > >> email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
 > > >> For more options, visit
https://groups.google.com/groups/opt_out.
 > > >>
 > > >
 > > > In comparing katello notices to foreman audits, I really like
the foreman
 > > > audits because they tend to answer an admin's questions:
"What happened
 > > > in
 > > > the past day, by whom, and what changed?"
 > >
 > > +1
 > >
 > > I like the audit view.
 > >
 > > In Spacewalk/Satellite for example, it's only possible for very
few actions
 > > to find out who did what and when.
 > >
 > > >
 > > > The missing piece of audits is that they currently log only
successful
 > > > changes. If they could be augmented to show failures as well,
that would
 > > > be very helpful.
 > >
 > > And pending tasks (like host building?), maybe.
 > >
 > > I like VMware's way of showing status (at the bottom):
 > >
http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png
 > >
 > > You always have an idea of what's going on.
 >
 > That's a nice UI view: Slide up and then slide down to hide right
on the
 > page. Would let me monitor tasks while going about other admin
chores.
 >
 > >
 > > If something deserves a notice to the user, doesn't it deserve
to be
 > > audited?
 > > It seems like audits and notices could be one thing.  Urgent
user facing
 > > issues get :display => true or something.
 >
 > Agreed. Some sort of user pref on a per-audit basis to trigger
popping a
 > notice or not. "Argh! Bob from accounting is having trouble
logging in
 > again... Better set failed login audits to pop so I can remind
him his
 > password was reset from 1234."

FYI: I'm working on the task statuses rework in Katello right now
with improved
realtime reporting and auditing features. I will demo the work so
far on today
Katello sprint demo (I can give a deep dive later on as well). Ohad:
I really
recommand you to take a loot at that.

About the audit, I agree that it has a lot in common with user
notifications.
What we do right now is showing the user the recent actions he
triggered on resources.
We don't include however attempts that failed on model validations,
as nothing
was really affected from the resource point of view.

How it works: every modification action will have a task record
created (we
use dynflow for that). The task is used for both short running actions
(performing actions only locally in database) or distributed actions
(perofrming rest calls to tother services). The task is assigned to
every resource that is connected to that task somehow: there are
more task -> resource relations:

   * locks: when repository is being synced, we don't want to allow
other actions to be performed on that resource
   * links: the product that contains the repository is linked to
the task as well: this allows us to include
     the repository sync task in list of tasks under the product,
the same mechanism gets
     the task into the tasks of the organization.

Every task also holds all the information needed for auditing, the
data about the resource it was run
on top of and the user that triggered it. This allows us to show the
details of the task even
when the resource, that task was on, is deleted.

With this approach, we are also able very easily produce cli
examples for the tasks.

So for example, when I run repository synchronization, it shows up
in the repository tasks,
product tasks, provider tasks and organization tasks. Even when I
delete the provider, I will
still see the information about the action in organization tasks.

It would be probably worth doing a deep-dive on that.

-- Ivan

 >
 >
 > >
 > >
 > > --
 > > Stephen Benjamin
 > > stephen@bitbin.de <mailto:stephen@bitbin.de>
 > >
 > >
 >
 > --
 > You received this message because you are subscribed to the
Google Groups
 > "foreman-dev" group.
 > To unsubscribe from this group and stop receiving emails from it,
send an
 > email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
 > For more options, visit https://groups.google.com/groups/opt_out.
 >

--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.