Currently the user information is not stored when registering a content
host.
Requires adding a column to the database, “registered_by”, which would
remain null if registered by activation key, else populated with the user.
This information will be displayed on the system details UI, Content Host
Content would change to:
Registered [Date Registered]
Registered by [Username || activation key name]
Checkin [Checkin Date]
I could see a few issues with the 'registered by' display:
if an activation key were deleted, activation key record is destroyed,
so would want to store the information independent of the record itself.
If an activation key is deleted, do content hosts registered with
this key remain registered? If so, then if the content host is then
associated with a new activation key, do we want the information to reflect
the new activation key, or the original?
If a user is deleted, I believe the record is not destroyed, but might
be prudent to save that information independent of its record as well.
If the user the originally registered the system is deleted, will there name still be available in an audit trail somewhere?
···
----- Original Message -----
>
>
> RFE – show user who registered content host if not registered by Activation
> Key
>
> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
>
>
> Currently the user information is not stored when registering a content
> host.
>
> Requires adding a column to the database, “registered_by”, which would
> remain null if registered by activation key, else populated with the user.
>
>
> This information will be displayed on the system details UI, Content Host
> Content would change to:
>
> Registered [Date Registered]
>
> Registered by [Username || activation key name]
>
> Checkin [Checkin Date]
>
>
>
> I could see a few issues with the 'registered by' display:
>
>
> - if an activation key were deleted, activation key record is destroyed,
> so would want to store the information independent of the record itself.
> - If an activation key is deleted, do content hosts registered with
> this key remain registered? If so, then if the content host is then
> associated with a new activation key, do we want the information to
> reflect
> the new activation key, or the original?
> - If a user is deleted, I believe the record is not destroyed, but might
> be prudent to save that information independent of its record as well.
>
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it's prudent to save the
name independent of the record reference.
···
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
>
>
>
> ----- Original Message -----
> >
> >
> > RFE – show user who registered content host if not registered by
> Activation
> > Key
> >
> > BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> >
> >
> > Currently the user information is not stored when registering a content
> > host.
> >
> > Requires adding a column to the database, “registered_by”, which would
> > remain null if registered by activation key, else populated with the
> user.
> >
> >
> > This information will be displayed on the system details UI, Content
> Host
> > Content would change to:
> >
> > Registered [Date Registered]
> >
> > Registered by [Username || activation key name]
> >
> > Checkin [Checkin Date]
> >
> >
> >
> > I could see a few issues with the 'registered by' display:
> >
> >
> > - if an activation key were deleted, activation key record is
> destroyed,
> > so would want to store the information independent of the record
> itself.
> > - If an activation key is deleted, do content hosts registered
> with
> > this key remain registered? If so, then if the content host is
> then
> > associated with a new activation key, do we want the information
> to
> > reflect
> > the new activation key, or the original?
> > - If a user is deleted, I believe the record is not destroyed, but
> might
> > be prudent to save that information independent of its record as
> well.
> >
>
> If the user the originally registered the system is deleted, will there
> name still be available in an audit trail somewhere?
>
If record is not deleted (really?) then no need to save the name separately, imo.
···
----- Original Message -----
> It looks to me as though the name will still be available because the
> record is not destroyed. However, I still think it's prudent to save the
> name independent of the record reference.
>
> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
> >
> >
> >
> > ----- Original Message -----
> > >
> > >
> > > RFE – show user who registered content host if not registered by
> > Activation
> > > Key
> > >
> > > BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> > >
> > >
> > > Currently the user information is not stored when registering a content
> > > host.
> > >
> > > Requires adding a column to the database, “registered_by”, which would
> > > remain null if registered by activation key, else populated with the
> > user.
> > >
> > >
> > > This information will be displayed on the system details UI, Content
> > Host
> > > Content would change to:
> > >
> > > Registered [Date Registered]
> > >
> > > Registered by [Username || activation key name]
> > >
> > > Checkin [Checkin Date]
> > >
> > >
> > >
> > > I could see a few issues with the 'registered by' display:
> > >
> > >
> > > - if an activation key were deleted, activation key record is
> > destroyed,
> > > so would want to store the information independent of the record
> > itself.
> > > - If an activation key is deleted, do content hosts registered
> > with
> > > this key remain registered? If so, then if the content host is
> > then
> > > associated with a new activation key, do we want the information
> > to
> > > reflect
> > > the new activation key, or the original?
> > > - If a user is deleted, I believe the record is not destroyed, but
> > might
> > > be prudent to save that information independent of its record as
> > well.
> > >
> >
> > If the user the originally registered the system is deleted, will there
> > name still be available in an audit trail somewhere?
> >
>
Okay, I'll check and make sure on that, I have only briefly looked at User,
so I might be wrong there.
···
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
>
>
>
> ----- Original Message -----
> > It looks to me as though the name will still be available because the
> > record is not destroyed. However, I still think it's prudent to save
> the
> > name independent of the record reference.
> >
> > On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
> > >
> > >
> > >
> > > ----- Original Message -----
> > > >
> > > >
> > > > RFE – show user who registered content host if not registered by
> > > Activation
> > > > Key
> > > >
> > > > BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> > > >
> > > >
> > > > Currently the user information is not stored when registering a
> content
> > > > host.
> > > >
> > > > Requires adding a column to the database, “registered_by”, which
> would
> > > > remain null if registered by activation key, else populated with the
> > > user.
> > > >
> > > >
> > > > This information will be displayed on the system details UI,
> Content
> > > Host
> > > > Content would change to:
> > > >
> > > > Registered [Date Registered]
> > > >
> > > > Registered by [Username || activation key name]
> > > >
> > > > Checkin [Checkin Date]
> > > >
> > > >
> > > >
> > > > I could see a few issues with the 'registered by' display:
> > > >
> > > >
> > > > - if an activation key were deleted, activation key record is
> > > destroyed,
> > > > so would want to store the information independent of the record
> > > itself.
> > > > - If an activation key is deleted, do content hosts registered
> > > with
> > > > this key remain registered? If so, then if the content host
> is
> > > then
> > > > associated with a new activation key, do we want the
> information
> > > to
> > > > reflect
> > > > the new activation key, or the original?
> > > > - If a user is deleted, I believe the record is not destroyed,
> but
> > > might
> > > > be prudent to save that information independent of its record as
> > > well.
> > > >
> > >
> > > If the user the originally registered the system is deleted, will
> there
> > > name still be available in an audit trail somewhere?
> > >
> >
>
> If record is not deleted (really?) then no need to save the name
> separately, imo.
>
···
On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant wrote:
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
···
On 07/14/2014 04:45 PM, Walden Raines wrote:
> I was just about to suggest this as well.
>
> I would prefer if we could solve the larger problem of auditing instead of adding this one-off column.
>
> Cheers,
> Walden
>
>
> ----- Original Message -----
> From: "Eric D Helms"
> To: "foreman-dev"
> Cc: christinefouant@gmail.com, "Tom McKay"
> Sent: Monday, July 14, 2014 4:41:51 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content host database
>
> Would adding https://github.com/collectiveidea/audited (which Foreman uses
> and provides already) handle this for us?
>
> Eric
>
>
> On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant > wrote:
>
>> Okay, I'll check and make sure on that, I have only briefly looked at
>> User, so I might be wrong there.
>>
>>
>> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> It looks to me as though the name will still be available because the
>>>> record is not destroyed. However, I still think it's prudent to save
>>> the
>>>> name independent of the record reference.
>>>>
>>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>>
>>>>>> RFE – show user who registered content host if not registered by
>>>>> Activation
>>>>>> Key
>>>>>>
>>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
>>>>>>
>>>>>>
>>>>>> Currently the user information is not stored when registering a
>>> content
>>>>>> host.
>>>>>>
>>>>>> Requires adding a column to the database, “registered_by”, which
>>> would
>>>>>> remain null if registered by activation key, else populated with
>>> the
>>>>> user.
>>>>>>
>>>>>>
>>>>>> This information will be displayed on the system details UI,
>>> Content
>>>>> Host
>>>>>> Content would change to:
>>>>>>
>>>>>> Registered [Date Registered]
>>>>>>
>>>>>> Registered by [Username || activation key name]
>>>>>>
>>>>>> Checkin [Checkin Date]
>>>>>>
>>>>>>
>>>>>>
>>>>>> I could see a few issues with the 'registered by' display:
>>>>>>
>>>>>>
>>>>>> - if an activation key were deleted, activation key record is
>>>>> destroyed,
>>>>>> so would want to store the information independent of the record
>>>>> itself.
>>>>>> - If an activation key is deleted, do content hosts
>>> registered
>>>>> with
>>>>>> this key remain registered? If so, then if the content host
>>> is
>>>>> then
>>>>>> associated with a new activation key, do we want the
>>> information
>>>>> to
>>>>>> reflect
>>>>>> the new activation key, or the original?
>>>>>> - If a user is deleted, I believe the record is not destroyed,
>>> but
>>>>> might
>>>>>> be prudent to save that information independent of its record as
>>>>> well.
>>>>>>
>>>>>
>>>>> If the user the originally registered the system is deleted, will
>>> there
>>>>> name still be available in an audit trail somewhere?
>>>>>
>>>>
>>>
>>> If record is not deleted (really?) then no need to save the name
>>> separately, imo.
>>>
>> --
>> 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/d/optout.
>>
>
> I was just about to suggest this as well.
>
> I would prefer if we could solve the larger problem of auditing instead of adding this one-off column.
>
> Cheers,
> Walden
How easy is it to link to an object's audit trail in the database and
reference it when necessary? Is the audited gem even the appropriate
solution for this?
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
> > I was just about to suggest this as well.
> >
> > I would prefer if we could solve the larger problem of auditing instead of
> > adding this one-off column.
> >
> > Cheers,
> > Walden
> How easy is it to link to an object's audit trail in the database and
> reference it when necessary? Is the audited gem even the appropriate
> solution for this?
>
> -Justin
>
Can dynflow be leveraged?
···
----- Original Message -----
> On 07/14/2014 04:45 PM, Walden Raines wrote:
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
> Is the audited gem even the appropriate solution for this?
Perhaps I'm misunderstanding the problem but it seems to be.
Cheers,
Walden
···
----- Original Message -----
From: "Justin Sherrill"
To: foreman-dev@googlegroups.com
Sent: Monday, July 14, 2014 4:55:11 PM
Subject: Re: [foreman-dev] Adding registered_by field to content host database
On 07/14/2014 04:45 PM, Walden Raines wrote:
I was just about to suggest this as well.
I would prefer if we could solve the larger problem of auditing instead of adding this one-off column.
Cheers,
Walden
How easy is it to link to an object’s audit trail in the database and
reference it when necessary? Is the audited gem even the appropriate
solution for this?
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
The problem I see (and I think Justin is talking about) is that audited
relies on the ActiveRecord data and there's nothing in System that holds
User data nor is there a relationship between System and User.
That said, I think we could maybe use the current user tracking feature of
audited:
···
On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
>
> > How easy is it to link to an object's audit trail in the database and
> > reference it when necessary?
>
> Looks like it's just object.audits (
> https://github.com/collectiveidea/audited#usage). We could probably
> include that in the rabl if we wanted to.
>
> > Is the audited gem even the appropriate solution for this?
>
> Perhaps I'm misunderstanding the problem but it seems to be.
>
> Cheers,
> Walden
>
> ----- Original Message -----
> From: "Justin Sherrill" <jshe...@redhat.com >
> To: forem...@googlegroups.com
> Sent: Monday, July 14, 2014 4:55:11 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content host
> database
>
> On 07/14/2014 04:45 PM, Walden Raines wrote:
> > I was just about to suggest this as well.
> >
> > I would prefer if we could solve the larger problem of auditing instead
> of adding this one-off column.
> >
> > Cheers,
> > Walden
> How easy is it to link to an object's audit trail in the database and
> reference it when necessary? Is the audited gem even the appropriate
> solution for this?
>
> -Justin
>
> >
> >
> > ----- Original Message -----
> > From: "Eric D Helms" <ericd...@gmail.com >
> > To: "foreman-dev" <forem...@googlegroups.com >
> > Cc: christi...@gmail.com , "Tom McKay" >
> > Sent: Monday, July 14, 2014 4:41:51 PM
> > Subject: Re: [foreman-dev] Adding registered_by field to content host
> database
> >
> > Would adding https://github.com/collectiveidea/audited (which Foreman
> uses
> > and provides already) handle this for us?
> >
> > Eric
> >
> >
> > On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant > >> wrote:
> >> Okay, I'll check and make sure on that, I have only briefly looked at
> >> User, so I might be wrong there.
> >>
> >>
> >> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> It looks to me as though the name will still be available because the
> >>>> record is not destroyed. However, I still think it's prudent to save
> >>> the
> >>>> name independent of the record reference.
> >>>>
> >>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>>
> >>>>>> RFE – show user who registered content host if not registered by
> >>>>> Activation
> >>>>>> Key
> >>>>>>
> >>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> >>>>>>
> >>>>>>
> >>>>>> Currently the user information is not stored when registering a
> >>> content
> >>>>>> host.
> >>>>>>
> >>>>>> Requires adding a column to the database, “registered_by”, which
> >>> would
> >>>>>> remain null if registered by activation key, else populated with
> >>> the
> >>>>> user.
> >>>>>>
> >>>>>> This information will be displayed on the system details UI,
> >>> Content
> >>>>> Host
> >>>>>> Content would change to:
> >>>>>>
> >>>>>> Registered [Date Registered]
> >>>>>>
> >>>>>> Registered by [Username || activation key name]
> >>>>>>
> >>>>>> Checkin [Checkin Date]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I could see a few issues with the 'registered by' display:
> >>>>>>
> >>>>>>
> >>>>>> - if an activation key were deleted, activation key record is
> >>>>> destroyed,
> >>>>>> so would want to store the information independent of the
> record
> >>>>> itself.
> >>>>>> - If an activation key is deleted, do content hosts
> >>> registered
> >>>>> with
> >>>>>> this key remain registered? If so, then if the content host
> >>> is
> >>>>> then
> >>>>>> associated with a new activation key, do we want the
> >>> information
> >>>>> to
> >>>>>> reflect
> >>>>>> the new activation key, or the original?
> >>>>>> - If a user is deleted, I believe the record is not destroyed,
> >>> but
> >>>>> might
> >>>>>> be prudent to save that information independent of its record
> as
> >>>>> well.
> >>>>> If the user the originally registered the system is deleted, will
> >>> there
> >>>>> name still be available in an audit trail somewhere?
> >>>>>
> >>> If record is not deleted (really?) then no need to save the name
> >>> separately, imo.
> >>>
> >> --
> >> 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...@googlegroups.com .
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>
> --
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>> How easy is it to link to an object's audit trail in the database and
>> reference it when necessary?
> Looks like it's just object.audits (https://github.com/collectiveidea/audited#usage). We could probably include that in the rabl if we wanted to.
>
>> Is the audited gem even the appropriate solution for this?
> Perhaps I'm misunderstanding the problem but it seems to be.
I was more pointing to the logic not being as simple as a small lookup.
As you need to handle:
a) if the user hasn't been deleted, use his current username
b) if the user has been deleted, lookup in the audit log his last
username (i presume) and show that
None of this is hard, but there are a number of gotchas you'd have to be
prepared for (can't use a foreign key, have to be prepared for the
object no longer existing) that i think are being ignored. I'd also
like to see this in a very generic way that can be reused easily. I'd
be okay with just doing users for now and doing activation keys once
that's actually audited.
-Justin
···
On 07/14/2014 05:02 PM, Walden Raines wrote:
Cheers,
Walden
----- Original Message -----
From: “Justin Sherrill” jsherril@redhat.com
To: foreman-dev@googlegroups.com
Sent: Monday, July 14, 2014 4:55:11 PM
Subject: Re: [foreman-dev] Adding registered_by field to content host database
On 07/14/2014 04:45 PM, Walden Raines wrote:
I was just about to suggest this as well.
I would prefer if we could solve the larger problem of auditing instead of adding this one-off column.
Cheers,
Walden
How easy is it to link to an object’s audit trail in the database and
reference it when necessary? Is the audited gem even the appropriate
solution for this?
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
> The problem I see (and I think Justin is talking about) is that
> audited relies on the ActiveRecord data and there's nothing in System
> that holds User data nor is there a relationship between System and User.
>
> That said, I think we could maybe use the current user tracking
> feature of audited:
>
> https://github.com/collectiveidea/audited#current-user-tracking
but extended to other objects and attributes (ActivationKey#name for
example)
···
On 07/14/2014 05:23 PM, David Davis wrote:
On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
> How easy is it to link to an object's audit trail in the
database and
> reference it when necessary?
Looks like it's just object.audits
(https://github.com/collectiveidea/audited#usage
<https://github.com/collectiveidea/audited#usage>). We could
probably include that in the rabl if we wanted to.
> Is the audited gem even the appropriate solution for this?
Perhaps I'm misunderstanding the problem but it seems to be.
Cheers,
Walden
----- Original Message -----
From: "Justin Sherrill" <jshe...@redhat.com <javascript:>>
To: forem...@googlegroups.com <javascript:>
Sent: Monday, July 14, 2014 4:55:11 PM
Subject: Re: [foreman-dev] Adding registered_by field to content
host database
On 07/14/2014 04:45 PM, Walden Raines wrote:
> I was just about to suggest this as well.
>
> I would prefer if we could solve the larger problem of auditing
instead of adding this one-off column.
>
> Cheers,
> Walden
How easy is it to link to an object's audit trail in the database and
reference it when necessary? Is the audited gem even the appropriate
solution for this?
-Justin
>
>
> ----- Original Message -----
> From: "Eric D Helms" <ericd...@gmail.com <javascript:>>
> To: "foreman-dev" <forem...@googlegroups.com <javascript:>>
> Cc: christi...@gmail.com <javascript:>, "Tom McKay"
<thoma...@redhat.com <javascript:>>
> Sent: Monday, July 14, 2014 4:41:51 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content
host database
>
> Would adding https://github.com/collectiveidea/audited
<https://github.com/collectiveidea/audited> (which Foreman uses
> and provides already) handle this for us?
>
> Eric
>
>
> On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant > <christi...@gmail.com <javascript:> > >> wrote:
>> Okay, I'll check and make sure on that, I have only briefly
looked at
>> User, so I might be wrong there.
>>
>>
>> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> It looks to me as though the name will still be available
because the
>>>> record is not destroyed. However, I still think it's prudent
to save
>>> the
>>>> name independent of the record reference.
>>>>
>>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>>
>>>>>> RFE – show user who registered content host if not
registered by
>>>>> Activation
>>>>>> Key
>>>>>>
>>>>>> BZ 1020402 -
https://bugzilla.redhat.com/show_bug.cgi?id=1020402
<https://bugzilla.redhat.com/show_bug.cgi?id=1020402>
>>>>>>
>>>>>>
>>>>>> Currently the user information is not stored when
registering a
>>> content
>>>>>> host.
>>>>>>
>>>>>> Requires adding a column to the database,
“registered_by”, which
>>> would
>>>>>> remain null if registered by activation key, else populated
with
>>> the
>>>>> user.
>>>>>>
>>>>>> This information will be displayed on the system details UI,
>>> Content
>>>>> Host
>>>>>> Content would change to:
>>>>>>
>>>>>> Registered [Date Registered]
>>>>>>
>>>>>> Registered by [Username || activation key name]
>>>>>>
>>>>>> Checkin [Checkin Date]
>>>>>>
>>>>>>
>>>>>>
>>>>>> I could see a few issues with the 'registered by' display:
>>>>>>
>>>>>>
>>>>>> - if an activation key were deleted, activation key
record is
>>>>> destroyed,
>>>>>> so would want to store the information independent of
the record
>>>>> itself.
>>>>>> - If an activation key is deleted, do content hosts
>>> registered
>>>>> with
>>>>>> this key remain registered? If so, then if the
content host
>>> is
>>>>> then
>>>>>> associated with a new activation key, do we want the
>>> information
>>>>> to
>>>>>> reflect
>>>>>> the new activation key, or the original?
>>>>>> - If a user is deleted, I believe the record is not
destroyed,
>>> but
>>>>> might
>>>>>> be prudent to save that information independent of its
record as
>>>>> well.
>>>>> If the user the originally registered the system is deleted,
will
>>> there
>>>>> name still be available in an audit trail somewhere?
>>>>>
>>> If record is not deleted (really?) then no need to save the name
>>> separately, imo.
>>>
>> --
>> 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...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
>>
--
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...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
But does audited create a foreign key or just record the data at the time it exists? It would be dumb if it relied on the ActiveRecord data to be there, it shouldn't.
Just looking briefly at their code I couldn't see any mention of foreign keys [1].
This is why I'm still a proponent of using a status for deleted items rather than actually removing the rows. Doing so would solve most of the gotchas mentioned (although perhaps uncover more).
From: “David Davis” david@memorious.net
To: foreman-dev@googlegroups.com
Sent: Monday, July 14, 2014 5:23:46 PM
Subject: Re: [foreman-dev] Adding registered_by field to content host database
The problem I see (and I think Justin is talking about) is that audited relies on the ActiveRecord data and there’s nothing in System that holds User data nor is there a relationship between System and User.
That said, I think we could maybe use the current user tracking feature of audited:
Is the audited gem even the appropriate solution for this?
Perhaps I’m misunderstanding the problem but it seems to be.
Cheers,
Walden
----- Original Message -----
From: “Justin Sherrill” < jshe...@redhat.com >
To: forem...@googlegroups.com
Sent: Monday, July 14, 2014 4:55:11 PM
Subject: Re: [foreman-dev] Adding registered_by field to content host database
On 07/14/2014 04:45 PM, Walden Raines wrote:
I was just about to suggest this as well.
I would prefer if we could solve the larger problem of auditing instead of adding this one-off column.
Cheers,
Walden
How easy is it to link to an object’s audit trail in the database and
reference it when necessary? Is the audited gem even the appropriate
solution for this?
On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant < christi...@gmail.com >> wrote:
Okay, I’ll check and make sure on that, I have only briefly looked at
User, so I might be wrong there.
On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
----- Original Message -----
It looks to me as though the name will still be available because the
record is not destroyed. However, I still think it’s prudent to save
the
name independent of the record reference.
On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
----- Original Message -----
RFE – show user who registered content host if not registered by
Activation
Key
Currently the user information is not stored when registering a
content
host.
Requires adding a column to the database, “registered_by”, which
would
remain null if registered by activation key, else populated with
the
user.
This information will be displayed on the system details UI,
Content
Host
Content would change to:
Registered [Date Registered]
Registered by [Username || activation key name]
Checkin [Checkin Date]
I could see a few issues with the ‘registered by’ display:
if an activation key were deleted, activation key record is
destroyed,
so would want to store the information independent of the record
itself.
If an activation key is deleted, do content hosts
registered
with
this key remain registered? If so, then if the content host
is
then
associated with a new activation key, do we want the
information
to
reflect
the new activation key, or the original?
If a user is deleted, I believe the record is not destroyed,
but
might
be prudent to save that information independent of its record as
well.
If the user the originally registered the system is deleted, will
there
name still be available in an audit trail somewhere?
If record is not deleted (really?) then no need to save the name
separately, imo.
–
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...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .
–
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...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout .
So I'm not really sure what auditing consists of, but keep in mind that if
it were registered with an activation key, we would be showing the name of
the activation key rather than the user name, if this makes a difference or
not. During my initial foray into looking at how to handle the request, I
was starting with the candlepin proxies controller and accessing the user
info there. However, it sounds like you're probably wanting to go with a
broader solution, so I might just need to step back and listen while the
sage ones discuss.
···
On Monday, July 14, 2014 5:36:10 PM UTC-4, jsherril wrote:
>
> On 07/14/2014 05:23 PM, David Davis wrote:
>
> The problem I see (and I think Justin is talking about) is that audited
> relies on the ActiveRecord data and there's nothing in System that holds
> User data nor is there a relationship between System and User.
>
> That said, I think we could maybe use the current user tracking feature
> of audited:
>
> https://github.com/collectiveidea/audited#current-user-tracking
>
> but extended to other objects and attributes (ActivationKey#name for
> example)
>
>
> On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
>>
>> > How easy is it to link to an object's audit trail in the database and
>> > reference it when necessary?
>>
>> Looks like it's just object.audits (
>> https://github.com/collectiveidea/audited#usage). We could probably
>> include that in the rabl if we wanted to.
>>
>> > Is the audited gem even the appropriate solution for this?
>>
>> Perhaps I'm misunderstanding the problem but it seems to be.
>>
>> Cheers,
>> Walden
>>
>> ----- Original Message -----
>> From: "Justin Sherrill"
>> To: forem...@googlegroups.com
>> Sent: Monday, July 14, 2014 4:55:11 PM
>> Subject: Re: [foreman-dev] Adding registered_by field to content host
>> database
>>
>> On 07/14/2014 04:45 PM, Walden Raines wrote:
>> > I was just about to suggest this as well.
>> >
>> > I would prefer if we could solve the larger problem of auditing instead
>> of adding this one-off column.
>> >
>> > Cheers,
>> > Walden
>> How easy is it to link to an object's audit trail in the database and
>> reference it when necessary? Is the audited gem even the appropriate
>> solution for this?
>>
>> -Justin
>>
>> >
>> >
>> > ----- Original Message -----
>> > From: "Eric D Helms"
>> > To: "foreman-dev"
>> > Cc: christi...@gmail.com, "Tom McKay"
>> > Sent: Monday, July 14, 2014 4:41:51 PM
>> > Subject: Re: [foreman-dev] Adding registered_by field to content host
>> database
>> >
>> > Would adding https://github.com/collectiveidea/audited (which Foreman
>> uses
>> > and provides already) handle this for us?
>> >
>> > Eric
>> >
>> >
>> > On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant > >> wrote:
>> >> Okay, I'll check and make sure on that, I have only briefly looked at
>> >> User, so I might be wrong there.
>> >>
>> >>
>> >> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
>> >>>
>> >>>
>> >>> ----- Original Message -----
>> >>>> It looks to me as though the name will still be available because
>> the
>> >>>> record is not destroyed. However, I still think it's prudent to
>> save
>> >>> the
>> >>>> name independent of the record reference.
>> >>>>
>> >>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
>> >>>>>
>> >>>>>
>> >>>>> ----- Original Message -----
>> >>>>>>
>> >>>>>> RFE – show user who registered content host if not registered by
>> >>>>> Activation
>> >>>>>> Key
>> >>>>>>
>> >>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
>> >>>>>>
>> >>>>>>
>> >>>>>> Currently the user information is not stored when registering a
>> >>> content
>> >>>>>> host.
>> >>>>>>
>> >>>>>> Requires adding a column to the database, “registered_by”, which
>> >>> would
>> >>>>>> remain null if registered by activation key, else populated with
>> >>> the
>> >>>>> user.
>> >>>>>>
>> >>>>>> This information will be displayed on the system details UI,
>> >>> Content
>> >>>>> Host
>> >>>>>> Content would change to:
>> >>>>>>
>> >>>>>> Registered [Date Registered]
>> >>>>>>
>> >>>>>> Registered by [Username || activation key name]
>> >>>>>>
>> >>>>>> Checkin [Checkin Date]
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> I could see a few issues with the 'registered by' display:
>> >>>>>>
>> >>>>>>
>> >>>>>> - if an activation key were deleted, activation key record is
>> >>>>> destroyed,
>> >>>>>> so would want to store the information independent of the
>> record
>> >>>>> itself.
>> >>>>>> - If an activation key is deleted, do content hosts
>> >>> registered
>> >>>>> with
>> >>>>>> this key remain registered? If so, then if the content
>> host
>> >>> is
>> >>>>> then
>> >>>>>> associated with a new activation key, do we want the
>> >>> information
>> >>>>> to
>> >>>>>> reflect
>> >>>>>> the new activation key, or the original?
>> >>>>>> - If a user is deleted, I believe the record is not destroyed,
>> >>> but
>> >>>>> might
>> >>>>>> be prudent to save that information independent of its record
>> as
>> >>>>> well.
>> >>>>> If the user the originally registered the system is deleted, will
>> >>> there
>> >>>>> name still be available in an audit trail somewhere?
>> >>>>>
>> >>> If record is not deleted (really?) then no need to save the name
>> >>> separately, imo.
>> >>>
>> >> --
>> >> 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...@googlegroups.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>>
>> --
>> 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...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> But does audited create a foreign key or just record the data at the time it exists?
It looks like it has a user_id, user_type, and username so both maybe? Not sure.
> This is why I'm still a proponent of using a status for deleted items rather
> than actually removing the rows.
+1. I've been pushing for this as well. I've always done this in the past at my old jobs.
> So I'm not really sure what auditing consists of, but keep in mind that if it were registered with an activation key, we would be > showing the name of the activation key rather than the user name, if this makes a difference or not.
So theoretically with the audited solution, I think what you'd want to do is store an association on System to activation keys [1] so you could see if there was a key on create. You'd always have the user info there but you'd have code to show/hide it based on whether there was an activation key at the time of creation. I think that would work but don't quote me on that.
···
----- Original Message -----
> From: "Walden Raines"
> To: foreman-dev@googlegroups.com
> Sent: Monday, July 14, 2014 5:46:57 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content host database
>
> But does audited create a foreign key or just record the data at the time it
> exists? It would be dumb if it relied on the ActiveRecord data to be there,
> it shouldn't.
>
> Just looking briefly at their code I couldn't see any mention of foreign keys
> [1].
>
> This is why I'm still a proponent of using a status for deleted items rather
> than actually removing the rows. Doing so would solve most of the gotchas
> mentioned (although perhaps uncover more).
>
> Cheers,
> Walden
>
> [1]
> https://github.com/collectiveidea/audited/blob/master/lib/generators/audited/templates/install.rb
>
>
>
> ----- Original Message -----
>
> From: "David Davis"
> To: foreman-dev@googlegroups.com
> Sent: Monday, July 14, 2014 5:23:46 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content host
> database
>
> The problem I see (and I think Justin is talking about) is that audited
> relies on the ActiveRecord data and there's nothing in System that holds
> User data nor is there a relationship between System and User.
>
> That said, I think we could maybe use the current user tracking feature of
> audited:
>
> https://github.com/collectiveidea/audited#current-user-tracking
>
> On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
>
> > How easy is it to link to an object's audit trail in the database and
> > reference it when necessary?
>
> Looks like it's just object.audits (
> https://github.com/collectiveidea/audited#usage ). We could probably include
> that in the rabl if we wanted to.
>
> > Is the audited gem even the appropriate solution for this?
>
> Perhaps I'm misunderstanding the problem but it seems to be.
>
> Cheers,
> Walden
>
> ----- Original Message -----
> From: "Justin Sherrill" < jshe...@redhat.com >
> To: forem...@googlegroups.com
> Sent: Monday, July 14, 2014 4:55:11 PM
> Subject: Re: [foreman-dev] Adding registered_by field to content host
> database
>
> On 07/14/2014 04:45 PM, Walden Raines wrote:
> > I was just about to suggest this as well.
> >
> > I would prefer if we could solve the larger problem of auditing instead of
> > adding this one-off column.
> >
> > Cheers,
> > Walden
> How easy is it to link to an object's audit trail in the database and
> reference it when necessary? Is the audited gem even the appropriate
> solution for this?
>
> -Justin
>
> >
> >
> > ----- Original Message -----
> > From: "Eric D Helms" < ericd...@gmail.com >
> > To: "foreman-dev" < forem...@googlegroups.com >
> > Cc: christi...@gmail.com , "Tom McKay" < thoma...@redhat.com >
> > Sent: Monday, July 14, 2014 4:41:51 PM
> > Subject: Re: [foreman-dev] Adding registered_by field to content host
> > database
> >
> > Would adding https://github.com/collectiveidea/audited (which Foreman uses
> > and provides already) handle this for us?
> >
> > Eric
> >
> >
> > On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant < christi...@gmail.com > >> wrote:
> >> Okay, I'll check and make sure on that, I have only briefly looked at
> >> User, so I might be wrong there.
> >>
> >>
> >> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> It looks to me as though the name will still be available because the
> >>>> record is not destroyed. However, I still think it's prudent to save
> >>> the
> >>>> name independent of the record reference.
> >>>>
> >>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>>
> >>>>>> RFE – show user who registered content host if not registered by
> >>>>> Activation
> >>>>>> Key
> >>>>>>
> >>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> >>>>>>
> >>>>>>
> >>>>>> Currently the user information is not stored when registering a
> >>> content
> >>>>>> host.
> >>>>>>
> >>>>>> Requires adding a column to the database, “registered_by”, which
> >>> would
> >>>>>> remain null if registered by activation key, else populated with
> >>> the
> >>>>> user.
> >>>>>>
> >>>>>> This information will be displayed on the system details UI,
> >>> Content
> >>>>> Host
> >>>>>> Content would change to:
> >>>>>>
> >>>>>> Registered [Date Registered]
> >>>>>>
> >>>>>> Registered by [Username || activation key name]
> >>>>>>
> >>>>>> Checkin [Checkin Date]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> I could see a few issues with the 'registered by' display:
> >>>>>>
> >>>>>>
> >>>>>> - if an activation key were deleted, activation key record is
> >>>>> destroyed,
> >>>>>> so would want to store the information independent of the record
> >>>>> itself.
> >>>>>> - If an activation key is deleted, do content hosts
> >>> registered
> >>>>> with
> >>>>>> this key remain registered? If so, then if the content host
> >>> is
> >>>>> then
> >>>>>> associated with a new activation key, do we want the
> >>> information
> >>>>> to
> >>>>>> reflect
> >>>>>> the new activation key, or the original?
> >>>>>> - If a user is deleted, I believe the record is not destroyed,
> >>> but
> >>>>> might
> >>>>>> be prudent to save that information independent of its record as
> >>>>> well.
> >>>>> If the user the originally registered the system is deleted, will
> >>> there
> >>>>> name still be available in an audit trail somewhere?
> >>>>>
> >>> If record is not deleted (really?) then no need to save the name
> >>> separately, imo.
> >>>
> >> --
> >> 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...@googlegroups.com .
> >> For more options, visit https://groups.google.com/d/optout .
> >>
>
> --
> 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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout .
>
>
>
>
>
> --
> 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/d/optout .
>
> --
> 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/d/optout.
>
···
On Monday, July 14, 2014 6:03:41 PM UTC-4, David Davis wrote:
>
> > But does audited create a foreign key or just record the data at the
> time it exists?
>
> It looks like it has a user_id, user_type, and username so both maybe? Not
> sure.
>
> > This is why I'm still a proponent of using a status for deleted items
> rather
> > than actually removing the rows.
>
> +1. I've been pushing for this as well. I've always done this in the past
> at my old jobs.
>
> > So I'm not really sure what auditing consists of, but keep in mind that
> if it were registered with an activation key, we would be > showing the
> name of the activation key rather than the user name, if this makes a
> difference or not.
>
> So theoretically with the audited solution, I think what you'd want to do
> is store an association on System to activation keys [1] so you could see
> if there was a key on create. You'd always have the user info there but
> you'd have code to show/hide it based on whether there was an activation
> key at the time of creation. I think that would work but don't quote me on
> that.
>
> [1] https://github.com/collectiveidea/audited#associated-audits
>
> David
>
> ----- Original Message -----
> > From: "Walden Raines" <wal...@redhat.com >
> > To: forem...@googlegroups.com
> > Sent: Monday, July 14, 2014 5:46:57 PM
> > Subject: Re: [foreman-dev] Adding registered_by field to content host
> database
> >
> > But does audited create a foreign key or just record the data at the
> time it
> > exists? It would be dumb if it relied on the ActiveRecord data to be
> there,
> > it shouldn't.
> >
> > Just looking briefly at their code I couldn't see any mention of foreign
> keys
> > [1].
> >
> > This is why I'm still a proponent of using a status for deleted items
> rather
> > than actually removing the rows. Doing so would solve most of the
> gotchas
> > mentioned (although perhaps uncover more).
> >
> > Cheers,
> > Walden
> >
> > [1]
> >
> https://github.com/collectiveidea/audited/blob/master/lib/generators/audited/templates/install.rb
> >
> >
> >
> > ----- Original Message -----
> >
> > From: "David Davis" <da...@memorious.net >
> > To: forem...@googlegroups.com
> > Sent: Monday, July 14, 2014 5:23:46 PM
> > Subject: Re: [foreman-dev] Adding registered_by field to content host
> > database
> >
> > The problem I see (and I think Justin is talking about) is that audited
> > relies on the ActiveRecord data and there's nothing in System that holds
> > User data nor is there a relationship between System and User.
> >
> > That said, I think we could maybe use the current user tracking feature
> of
> > audited:
> >
> > https://github.com/collectiveidea/audited#current-user-tracking
> >
> > On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
> >
> > > How easy is it to link to an object's audit trail in the database and
> > > reference it when necessary?
> >
> > Looks like it's just object.audits (
> > https://github.com/collectiveidea/audited#usage ). We could probably
> include
> > that in the rabl if we wanted to.
> >
> > > Is the audited gem even the appropriate solution for this?
> >
> > Perhaps I'm misunderstanding the problem but it seems to be.
> >
> > Cheers,
> > Walden
> >
> > ----- Original Message -----
> > From: "Justin Sherrill" < jshe...@redhat.com >
> > To: forem...@googlegroups.com
> > Sent: Monday, July 14, 2014 4:55:11 PM
> > Subject: Re: [foreman-dev] Adding registered_by field to content host
> > database
> >
> > On 07/14/2014 04:45 PM, Walden Raines wrote:
> > > I was just about to suggest this as well.
> > >
> > > I would prefer if we could solve the larger problem of auditing
> instead of
> > > adding this one-off column.
> > >
> > > Cheers,
> > > Walden
> > How easy is it to link to an object's audit trail in the database and
> > reference it when necessary? Is the audited gem even the appropriate
> > solution for this?
> >
> > -Justin
> >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Eric D Helms" < ericd...@gmail.com >
> > > To: "foreman-dev" < forem...@googlegroups.com >
> > > Cc: christi...@gmail.com , "Tom McKay" < thoma...@redhat.com >
> > > Sent: Monday, July 14, 2014 4:41:51 PM
> > > Subject: Re: [foreman-dev] Adding registered_by field to content host
> > > database
> > >
> > > Would adding https://github.com/collectiveidea/audited (which Foreman
> uses
> > > and provides already) handle this for us?
> > >
> > > Eric
> > >
> > >
> > > On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant < > christi...@gmail.com > > >> wrote:
> > >> Okay, I'll check and make sure on that, I have only briefly looked at
> > >> User, so I might be wrong there.
> > >>
> > >>
> > >> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> It looks to me as though the name will still be available because
> the
> > >>>> record is not destroyed. However, I still think it's prudent to
> save
> > >>> the
> > >>>> name independent of the record reference.
> > >>>>
> > >>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>>
> > >>>>>> RFE – show user who registered content host if not registered by
> > >>>>> Activation
> > >>>>>> Key
> > >>>>>>
> > >>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
> > >>>>>>
> > >>>>>>
> > >>>>>> Currently the user information is not stored when registering a
> > >>> content
> > >>>>>> host.
> > >>>>>>
> > >>>>>> Requires adding a column to the database, “registered_by”, which
> > >>> would
> > >>>>>> remain null if registered by activation key, else populated with
> > >>> the
> > >>>>> user.
> > >>>>>>
> > >>>>>> This information will be displayed on the system details UI,
> > >>> Content
> > >>>>> Host
> > >>>>>> Content would change to:
> > >>>>>>
> > >>>>>> Registered [Date Registered]
> > >>>>>>
> > >>>>>> Registered by [Username || activation key name]
> > >>>>>>
> > >>>>>> Checkin [Checkin Date]
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> I could see a few issues with the 'registered by' display:
> > >>>>>>
> > >>>>>>
> > >>>>>> - if an activation key were deleted, activation key record is
> > >>>>> destroyed,
> > >>>>>> so would want to store the information independent of the record
> > >>>>> itself.
> > >>>>>> - If an activation key is deleted, do content hosts
> > >>> registered
> > >>>>> with
> > >>>>>> this key remain registered? If so, then if the content host
> > >>> is
> > >>>>> then
> > >>>>>> associated with a new activation key, do we want the
> > >>> information
> > >>>>> to
> > >>>>>> reflect
> > >>>>>> the new activation key, or the original?
> > >>>>>> - If a user is deleted, I believe the record is not destroyed,
> > >>> but
> > >>>>> might
> > >>>>>> be prudent to save that information independent of its record as
> > >>>>> well.
> > >>>>> If the user the originally registered the system is deleted, will
> > >>> there
> > >>>>> name still be available in an audit trail somewhere?
> > >>>>>
> > >>> If record is not deleted (really?) then no need to save the name
> > >>> separately, imo.
> > >>>
> > >> --
> > >> 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...@googlegroups.com .
> > >> For more options, visit https://groups.google.com/d/optout .
> > >>
> >
> > --
> > 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...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout .
> >
> >
> >
> >
> >
> > --
> > 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...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout .
> >
> > --
> > 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...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
> >
>
I think it's mainly up to you. If you feel like you're up for a challenge,
try adding audited and use it to solve BZ1020402. Otherwise, I'd probably
go with a separate field.
···
On Friday, July 18, 2014 2:06:16 PM UTC-4, Christine Fouant wrote:
>
> So, any decisions yet on how to proceed?
>
> On Monday, July 14, 2014 6:03:41 PM UTC-4, David Davis wrote:
>>
>> > But does audited create a foreign key or just record the data at the
>> time it exists?
>>
>> It looks like it has a user_id, user_type, and username so both maybe?
>> Not sure.
>>
>> > This is why I'm still a proponent of using a status for deleted items
>> rather
>> > than actually removing the rows.
>>
>> +1. I've been pushing for this as well. I've always done this in the past
>> at my old jobs.
>>
>> > So I'm not really sure what auditing consists of, but keep in mind that
>> if it were registered with an activation key, we would be > showing the
>> name of the activation key rather than the user name, if this makes a
>> difference or not.
>>
>> So theoretically with the audited solution, I think what you'd want to do
>> is store an association on System to activation keys [1] so you could see
>> if there was a key on create. You'd always have the user info there but
>> you'd have code to show/hide it based on whether there was an activation
>> key at the time of creation. I think that would work but don't quote me on
>> that.
>>
>> [1] https://github.com/collectiveidea/audited#associated-audits
>>
>> David
>>
>> ----- Original Message -----
>> > From: "Walden Raines"
>> > To: forem...@googlegroups.com
>> > Sent: Monday, July 14, 2014 5:46:57 PM
>> > Subject: Re: [foreman-dev] Adding registered_by field to content host
>> database
>> >
>> > But does audited create a foreign key or just record the data at the
>> time it
>> > exists? It would be dumb if it relied on the ActiveRecord data to be
>> there,
>> > it shouldn't.
>> >
>> > Just looking briefly at their code I couldn't see any mention of
>> foreign keys
>> > [1].
>> >
>> > This is why I'm still a proponent of using a status for deleted items
>> rather
>> > than actually removing the rows. Doing so would solve most of the
>> gotchas
>> > mentioned (although perhaps uncover more).
>> >
>> > Cheers,
>> > Walden
>> >
>> > [1]
>> >
>> https://github.com/collectiveidea/audited/blob/master/lib/generators/audited/templates/install.rb
>> >
>> >
>> >
>> > ----- Original Message -----
>> >
>> > From: "David Davis"
>> > To: forem...@googlegroups.com
>> > Sent: Monday, July 14, 2014 5:23:46 PM
>> > Subject: Re: [foreman-dev] Adding registered_by field to content host
>> > database
>> >
>> > The problem I see (and I think Justin is talking about) is that audited
>> > relies on the ActiveRecord data and there's nothing in System that
>> holds
>> > User data nor is there a relationship between System and User.
>> >
>> > That said, I think we could maybe use the current user tracking feature
>> of
>> > audited:
>> >
>> > https://github.com/collectiveidea/audited#current-user-tracking
>> >
>> > On Monday, July 14, 2014 5:02:45 PM UTC-4, Walden Raines wrote:
>> >
>> > > How easy is it to link to an object's audit trail in the database and
>> > > reference it when necessary?
>> >
>> > Looks like it's just object.audits (
>> > https://github.com/collectiveidea/audited#usage ). We could probably
>> include
>> > that in the rabl if we wanted to.
>> >
>> > > Is the audited gem even the appropriate solution for this?
>> >
>> > Perhaps I'm misunderstanding the problem but it seems to be.
>> >
>> > Cheers,
>> > Walden
>> >
>> > ----- Original Message -----
>> > From: "Justin Sherrill" < jshe...@redhat.com >
>> > To: forem...@googlegroups.com
>> > Sent: Monday, July 14, 2014 4:55:11 PM
>> > Subject: Re: [foreman-dev] Adding registered_by field to content host
>> > database
>> >
>> > On 07/14/2014 04:45 PM, Walden Raines wrote:
>> > > I was just about to suggest this as well.
>> > >
>> > > I would prefer if we could solve the larger problem of auditing
>> instead of
>> > > adding this one-off column.
>> > >
>> > > Cheers,
>> > > Walden
>> > How easy is it to link to an object's audit trail in the database and
>> > reference it when necessary? Is the audited gem even the appropriate
>> > solution for this?
>> >
>> > -Justin
>> >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > From: "Eric D Helms" < ericd...@gmail.com >
>> > > To: "foreman-dev" < forem...@googlegroups.com >
>> > > Cc: christi...@gmail.com , "Tom McKay" < thoma...@redhat.com >
>> > > Sent: Monday, July 14, 2014 4:41:51 PM
>> > > Subject: Re: [foreman-dev] Adding registered_by field to content host
>> > > database
>> > >
>> > > Would adding https://github.com/collectiveidea/audited (which
>> Foreman uses
>> > > and provides already) handle this for us?
>> > >
>> > > Eric
>> > >
>> > >
>> > > On Mon, Jul 14, 2014 at 4:24 PM, Christine Fouant < >> christi...@gmail.com >> > >> wrote:
>> > >> Okay, I'll check and make sure on that, I have only briefly looked
>> at
>> > >> User, so I might be wrong there.
>> > >>
>> > >>
>> > >> On Monday, July 14, 2014 3:25:03 PM UTC-4, Tom McKay wrote:
>> > >>>
>> > >>>
>> > >>> ----- Original Message -----
>> > >>>> It looks to me as though the name will still be available because
>> the
>> > >>>> record is not destroyed. However, I still think it's prudent to
>> save
>> > >>> the
>> > >>>> name independent of the record reference.
>> > >>>>
>> > >>>> On Monday, July 14, 2014 2:11:38 PM UTC-4, Tom McKay wrote:
>> > >>>>>
>> > >>>>>
>> > >>>>> ----- Original Message -----
>> > >>>>>>
>> > >>>>>> RFE – show user who registered content host if not registered by
>> > >>>>> Activation
>> > >>>>>> Key
>> > >>>>>>
>> > >>>>>> BZ 1020402 - https://bugzilla.redhat.com/show_bug.cgi?id=1020402
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Currently the user information is not stored when registering a
>> > >>> content
>> > >>>>>> host.
>> > >>>>>>
>> > >>>>>> Requires adding a column to the database, “registered_by”, which
>> > >>> would
>> > >>>>>> remain null if registered by activation key, else populated with
>> > >>> the
>> > >>>>> user.
>> > >>>>>>
>> > >>>>>> This information will be displayed on the system details UI,
>> > >>> Content
>> > >>>>> Host
>> > >>>>>> Content would change to:
>> > >>>>>>
>> > >>>>>> Registered [Date Registered]
>> > >>>>>>
>> > >>>>>> Registered by [Username || activation key name]
>> > >>>>>>
>> > >>>>>> Checkin [Checkin Date]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> I could see a few issues with the 'registered by' display:
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> - if an activation key were deleted, activation key record is
>> > >>>>> destroyed,
>> > >>>>>> so would want to store the information independent of the record
>> > >>>>> itself.
>> > >>>>>> - If an activation key is deleted, do content hosts
>> > >>> registered
>> > >>>>> with
>> > >>>>>> this key remain registered? If so, then if the content host
>> > >>> is
>> > >>>>> then
>> > >>>>>> associated with a new activation key, do we want the
>> > >>> information
>> > >>>>> to
>> > >>>>>> reflect
>> > >>>>>> the new activation key, or the original?
>> > >>>>>> - If a user is deleted, I believe the record is not destroyed,
>> > >>> but
>> > >>>>> might
>> > >>>>>> be prudent to save that information independent of its record as
>> > >>>>> well.
>> > >>>>> If the user the originally registered the system is deleted, will
>> > >>> there
>> > >>>>> name still be available in an audit trail somewhere?
>> > >>>>>
>> > >>> If record is not deleted (really?) then no need to save the name
>> > >>> separately, imo.
>> > >>>
>> > >> --
>> > >> 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...@googlegroups.com .
>> > >> For more options, visit https://groups.google.com/d/optout .
>> > >>
>> >
>> > --
>> > 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...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout .
>> >
>> >
>> >
>> >
>> >
>> > --
>> > 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...@googlegroups.com .
>> > For more options, visit https://groups.google.com/d/optout .
>> >
>> > --
>> > 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...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>
