This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
Hi I was wondering if anyone has tried and had success with creating a script to add attributes to maxattributecfg. I went to create two attributes: one to indicate whether the user has altered an out of box attribute (user will click upon first edit), and another for comments related to the change(s).
Of course maxattributecfg is marked as internal so we are not able to add attributes from the front-end.
Kevin Wertz
Grifols Therapeutics
Clayton NC
I'd be inclined to create a new table to store the additional data rather than touching such critical tables, do you see any issue why your extra columns need to be in the master table?
Chris.
On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@gmail.com> wrote:
> Hi I was wondering if anyone has tried and had success with creating a script to add attributes to maxattributecfg. I went to create two attributes: one to indicate whether the user has altered an out of box attribute (user will click upon first edit), and another for comments related to the change(s).
>
> Of course maxattributecfg is marked as internal so we are not able to add attributes from the front-end.
>
> Kevin Wertz
> Grifols Therapeutics
> Clayton NC
>
>
I think you're right, seems like a better approach, no reason for those
columns to have to be in the master. So I tried that, created a new object
with the few attributes plus maxattributeid, created a relationship to the
new object/table maxattibuteid=:maxattributeid, then added the new checkbox
from the new object to the database config's attribute details section.
When I click the new checkbox (which appears editable), I get a message
that the new object is read-only. Any ideas? I'm guessing Maximo can't just
create the new row in my new table just because I clicked the checkbox from
that table.
KW
On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@gmail.com> wrote:
> **
>
>
> I'd be inclined to create a new table to store the additional data rather
> than touching such critical tables, do you see any issue why your extra
> columns need to be in the master table?
>
> Chris.
>
>
> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@gmail.com> wrote:
>
> > Hi I was wondering if anyone has tried and had success with creating a
> script to add attributes to maxattributecfg. I went to create two
> attributes: one to indicate whether the user has altered an out of box
> attribute (user will click upon first edit), and another for comments
> related to the change(s).
> >
> > Of course maxattributecfg is marked as internal so we are not able to
> add attributes from the front-end.
> >
> > Kevin Wertz
> > Grifols Therapeutics
> > Clayton NC
> >
> >
>
>
>
>
>
Well I created a companion row in my new table for the attribute where I
was trying to click the checkbox, and it worked.
So I guess I just have to create rows in my new table for all my current
attributes, then create a trigger that creates a new row in my new table
every time I add an attribute? If there's a simpler way to do this I'd love
to know.
KW
On Mon, Jul 2, 2012 at 4:29 PM, Kevin Wertz <wertzee@gmail.com> wrote:
> I think you're right, seems like a better approach, no reason for those
> columns to have to be in the master. So I tried that, created a new object
> with the few attributes plus maxattributeid, created a relationship to the
> new object/table maxattibuteid=:maxattributeid, then added the new checkbox
> from the new object to the database config's attribute details section.
> When I click the new checkbox (which appears editable), I get a message
> that the new object is read-only. Any ideas? I'm guessing Maximo can't just
> create the new row in my new table just because I clicked the checkbox from
> that table.
>
> KW
>
>
> On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@gmail.com> wrote:
>
>> **
>>
>>
>> I'd be inclined to create a new table to store the additional data rather
>> than touching such critical tables, do you see any issue why your extra
>> columns need to be in the master table?
>>
>> Chris.
>>
>>
>> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@gmail.com> wrote:
>>
>> > Hi I was wondering if anyone has tried and had success with creating a
>> script to add attributes to maxattributecfg. I went to create two
>> attributes: one to indicate whether the user has altered an out of box
>> attribute (user will click upon first edit), and another for comments
>> related to the change(s).
>> >
>> > Of course maxattributecfg is marked as internal so we are not able to
>> add attributes from the front-end.
>> >
>> > Kevin Wertz
>> > Grifols Therapeutics
>> > Clayton NC
>> >
>> >
>>
>>
>>
>>
>>
>
>
If it were me... I'd pre-populate the new table for all current attributes, that just leaves a gap when you're adding a new attribute or removing an attribute. What version of Maximo are you using? You could enhance things with automation scripts, RulesManager or Java extensions if you wanted to make it neat and tidy.
An alternative might be to use your new table as a child which you show in a table window and expect a user to create a "status" row for each change they make. You can pull down the parent details when you add a row, the only gap would be how you enforce rules to not allow a config unless the have filled out the details etc.
Can you enable audit for maxattributecfg? Just wondering...
Chris.
On Jul 2, 2012, at 16:56, Kevin Wertz <wertzee@gmail.com> wrote:
> Well I created a companion row in my new table for the attribute where I
> was trying to click the checkbox, and it worked.
>
> So I guess I just have to create rows in my new table for all my current
> attributes, then create a trigger that creates a new row in my new table
> every time I add an attribute? If there's a simpler way to do this I'd love
> to know.
>
> KW
>
> On Mon, Jul 2, 2012 at 4:29 PM, Kevin Wertz <wertzee@gmail.com> wrote:
>
>> I think you're right, seems like a better approach, no reason for those
>> columns to have to be in the master. So I tried that, created a new object
>> with the few attributes plus maxattributeid, created a relationship to the
>> new object/table maxattibuteid=:maxattributeid, then added the new checkbox
>> from the new object to the database config's attribute details section.
>> When I click the new checkbox (which appears editable), I get a message
>> that the new object is read-only. Any ideas? I'm guessing Maximo can't just
>> create the new row in my new table just because I clicked the checkbox from
>> that table.
>>
>> KW
>>
>>
>> On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@gmail.com> wrote:
>>
>>> **
>>>
>>>
>>> I'd be inclined to create a new table to store the additional data rather
>>> than touching such critical tables, do you see any issue why your extra
>>> columns need to be in the master table?
>>>
>>> Chris.
>>>
>>>
>>> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@gmail.com> wrote:
>>>
>>>> Hi I was wondering if anyone has tried and had success with creating a
>>> script to add attributes to maxattributecfg. I went to create two
>>> attributes: one to indicate whether the user has altered an out of box
>>> attribute (user will click upon first edit), and another for comments
>>> related to the change(s).
>>>>
>>>> Of course maxattributecfg is marked as internal so we are not able to
>>> add attributes from the front-end.
>>>>
>>>> Kevin Wertz
>>>> Grifols Therapeutics
>>>> Clayton NC
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
>
> ------------------------------------
>
> Email addresses you might need:
> Posting: MAXIMO@yahoogroups.com
> Join : MAXIMO-subscribe@yahoogroups.com
> Leave : MAXIMO-unsubscribe@yahoogroups.com
> Cry : MAXIMO-owner@yahoogroups.com
> Group : http://groups.yahoo.com/group/MAXIMOYahoo! Groups Links
>
>
>
Hi Kevin,
Interesting thread. It appears to me that you are trying to track if there was a change and what was the reason for the change. If that's the case, I'd leave your new table blank.
Only insert into it when an attribute changes or is added.
This is kinda like the e-audit capabilities.
So it becomes a log, of every change and why. If you have a record for each attribute, you will only be updating the last change.
I'd take it as far as showing date changed, who changed it, what the old value was, new value and reason for change or add.
The key is the version of Maximo you are using, as this would be cleaner with a dialog that pops up once you make the changes to an attribute to record the reason... and have that populate with everything else in the new row.
Sorry if I misunderstood in advance.
Based on your version, will try to give you the best way to do it.
Steve
--- In MAXIMO@yahoogroups.com, Kevin Wertz <wertzee@...> wrote:
>
> Well I created a companion row in my new table for the attribute where I
> was trying to click the checkbox, and it worked.
>
> So I guess I just have to create rows in my new table for all my current
> attributes, then create a trigger that creates a new row in my new table
> every time I add an attribute? If there's a simpler way to do this I'd love
> to know.
>
> KW
>
> On Mon, Jul 2, 2012 at 4:29 PM, Kevin Wertz <wertzee@...> wrote:
>
> > I think you're right, seems like a better approach, no reason for those
> > columns to have to be in the master. So I tried that, created a new object
> > with the few attributes plus maxattributeid, created a relationship to the
> > new object/table maxattibuteid=:maxattributeid, then added the new checkbox
> > from the new object to the database config's attribute details section.
> > When I click the new checkbox (which appears editable), I get a message
> > that the new object is read-only. Any ideas? I'm guessing Maximo can't just
> > create the new row in my new table just because I clicked the checkbox from
> > that table.
> >
> > KW
> >
> >
> > On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@...> wrote:
> >
> >> **
> >>
> >>
> >> I'd be inclined to create a new table to store the additional data rather
> >> than touching such critical tables, do you see any issue why your extra
> >> columns need to be in the master table?
> >>
> >> Chris.
> >>
> >>
> >> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@...> wrote:
> >>
> >> > Hi I was wondering if anyone has tried and had success with creating a
> >> script to add attributes to maxattributecfg. I went to create two
> >> attributes: one to indicate whether the user has altered an out of box
> >> attribute (user will click upon first edit), and another for comments
> >> related to the change(s).
> >> >
> >> > Of course maxattributecfg is marked as internal so we are not able to
> >> add attributes from the front-end.
> >> >
> >> > Kevin Wertz
> >> > Grifols Therapeutics
> >> > Clayton NC
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
>
>
Thanks guys, since you seem interested in what I'm trying to do I'll give
you a little background. This idea may be of interest to others as well.
We are a life science company, hence our EAM system is considered GxP and
therefore we have to validate it. Our validation plan, accepted by our
quality organization, is to only validate what we change out of the box. So
our design specification (DS) has a painstaking listing of every attribute
we have added, or existing OOB attributes that we have changed. Each row
has a comments column that allows a little writeup on what was changed or
why the new attribute was added. To make a change to the DS requires a site
change control process, so that means even just adding a simple checkbox
based on a new attribute requires a full blown change control.
We have changed ownership recently, and I have been challenged with trying
to reduce the amount of validation that we do without compromising quality.
Back when we did our v7 upgrade early last year, we revamped our DS to
remove all the screen shots and painstaking listing of the screen changes
we made out of box. The DS now only simply points to where our screen
definition xml's are stored and versioned in source safe. Now, we can make
changes to the screens (like adding a field with an already existing
attribute) using an administrative SOP that guides us through the process
of making the change, testing it, moving it to PROD, then checking it into
source safe with a comment on the changes made.
So basically, now I want to do the same thing with attributes, removing the
listing of attribute changes from the DS and pointing to results of a query
that we would run and check into source safe with each administrative SOP
change. So we are covered by the user defined flag for new attributes, but
how do I capture changes to existing OOB attributes? That's how this all
started.
Now to comment on the suggestions you both made. 1. I could turn on
auditing, but that still doesn't leave me a place for comments, and then
I'd have to figure out how to insert rows for all the changes we've already
made. 2. I thought of the idea of adding new rows in a table object for
each change, but the problem is that attributes are already in a table
object and obviously you can't put a table object within a table object.
I'm okay with the single comments box and just manually putting in the
change details. Very few OOB attributes have been changed more than once.
Kevin Wertz
Grifols Therapeutics
Clayton NC
On Mon, Jul 2, 2012 at 5:28 PM, Steve4FB <steve4fb@yahoo.com> wrote:
> **
>
>
> Hi Kevin,
>
> Interesting thread. It appears to me that you are trying to track if there
> was a change and what was the reason for the change. If that's the case,
> I'd leave your new table blank.
>
> Only insert into it when an attribute changes or is added.
>
> This is kinda like the e-audit capabilities.
>
> So it becomes a log, of every change and why. If you have a record for
> each attribute, you will only be updating the last change.
>
> I'd take it as far as showing date changed, who changed it, what the old
> value was, new value and reason for change or add.
>
> The key is the version of Maximo you are using, as this would be cleaner
> with a dialog that pops up once you make the changes to an attribute to
> record the reason... and have that populate with everything else in the new
> row.
>
> Sorry if I misunderstood in advance.
>
> Based on your version, will try to give you the best way to do it.
>
> Steve
>
>
> --- In MAXIMO@yahoogroups.com, Kevin Wertz <wertzee@...> wrote:
> >
> > Well I created a companion row in my new table for the attribute where I
> > was trying to click the checkbox, and it worked.
> >
> > So I guess I just have to create rows in my new table for all my current
> > attributes, then create a trigger that creates a new row in my new table
> > every time I add an attribute? If there's a simpler way to do this I'd
> love
> > to know.
> >
> > KW
> >
> > On Mon, Jul 2, 2012 at 4:29 PM, Kevin Wertz <wertzee@...> wrote:
> >
> > > I think you're right, seems like a better approach, no reason for those
> > > columns to have to be in the master. So I tried that, created a new
> object
> > > with the few attributes plus maxattributeid, created a relationship to
> the
> > > new object/table maxattibuteid=:maxattributeid, then added the new
> checkbox
> > > from the new object to the database config's attribute details section.
> > > When I click the new checkbox (which appears editable), I get a message
> > > that the new object is read-only. Any ideas? I'm guessing Maximo can't
> just
> > > create the new row in my new table just because I clicked the checkbox
> from
> > > that table.
> > >
> > > KW
> > >
> > >
> > > On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@...> wrote:
> > >
> > >> **
>
> > >>
> > >>
> > >> I'd be inclined to create a new table to store the additional data
> rather
> > >> than touching such critical tables, do you see any issue why your
> extra
> > >> columns need to be in the master table?
> > >>
> > >> Chris.
> > >>
> > >>
> > >> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@...> wrote:
> > >>
> > >> > Hi I was wondering if anyone has tried and had success with
> creating a
> > >> script to add attributes to maxattributecfg. I went to create two
> > >> attributes: one to indicate whether the user has altered an out of box
> > >> attribute (user will click upon first edit), and another for comments
> > >> related to the change(s).
> > >> >
> > >> > Of course maxattributecfg is marked as internal so we are not able
> to
> > >> add attributes from the front-end.
> > >> >
> > >> > Kevin Wertz
> > >> > Grifols Therapeutics
> > >> > Clayton NC
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
>
>
>
Okay so I went ahead and created the separate table and inserted rows to
match one for one with the rows in maxattributecfg. But here's a weird
error!
It works great, I am able to add values for my columns in the separate
table, UNLESS I filter the attributes first. In other words, if I filter
for the status attribute, my new values for "user altered" and "developer
details" just disappear into thin air after I save. Very strange. Anyone
seen something like this before and know how to fix it?
KW
On Tue, Jul 3, 2012 at 10:55 AM, Kevin Wertz <wertzee@gmail.com> wrote:
> Thanks guys, since you seem interested in what I'm trying to do I'll give
> you a little background. This idea may be of interest to others as well.
>
> We are a life science company, hence our EAM system is considered GxP and
> therefore we have to validate it. Our validation plan, accepted by our
> quality organization, is to only validate what we change out of the box. So
> our design specification (DS) has a painstaking listing of every attribute
> we have added, or existing OOB attributes that we have changed. Each row
> has a comments column that allows a little writeup on what was changed or
> why the new attribute was added. To make a change to the DS requires a site
> change control process, so that means even just adding a simple checkbox
> based on a new attribute requires a full blown change control.
>
> We have changed ownership recently, and I have been challenged with trying
> to reduce the amount of validation that we do without compromising quality.
> Back when we did our v7 upgrade early last year, we revamped our DS to
> remove all the screen shots and painstaking listing of the screen changes
> we made out of box. The DS now only simply points to where our screen
> definition xml's are stored and versioned in source safe. Now, we can make
> changes to the screens (like adding a field with an already existing
> attribute) using an administrative SOP that guides us through the process
> of making the change, testing it, moving it to PROD, then checking it into
> source safe with a comment on the changes made.
>
> So basically, now I want to do the same thing with attributes, removing
> the listing of attribute changes from the DS and pointing to results of a
> query that we would run and check into source safe with each administrative
> SOP change. So we are covered by the user defined flag for new attributes,
> but how do I capture changes to existing OOB attributes? That's how this
> all started.
>
> Now to comment on the suggestions you both made. 1. I could turn on
> auditing, but that still doesn't leave me a place for comments, and then
> I'd have to figure out how to insert rows for all the changes we've already
> made. 2. I thought of the idea of adding new rows in a table object for
> each change, but the problem is that attributes are already in a table
> object and obviously you can't put a table object within a table object.
>
> I'm okay with the single comments box and just manually putting in the
> change details. Very few OOB attributes have been changed more than once.
>
>
> Kevin Wertz
> Grifols Therapeutics
> Clayton NC
>
> On Mon, Jul 2, 2012 at 5:28 PM, Steve4FB <steve4fb@yahoo.com> wrote:
>
>> **
>>
>>
>> Hi Kevin,
>>
>> Interesting thread. It appears to me that you are trying to track if
>> there was a change and what was the reason for the change. If that's the
>> case, I'd leave your new table blank.
>>
>> Only insert into it when an attribute changes or is added.
>>
>> This is kinda like the e-audit capabilities.
>>
>> So it becomes a log, of every change and why. If you have a record for
>> each attribute, you will only be updating the last change.
>>
>> I'd take it as far as showing date changed, who changed it, what the old
>> value was, new value and reason for change or add.
>>
>> The key is the version of Maximo you are using, as this would be cleaner
>> with a dialog that pops up once you make the changes to an attribute to
>> record the reason... and have that populate with everything else in the new
>> row.
>>
>> Sorry if I misunderstood in advance.
>>
>> Based on your version, will try to give you the best way to do it.
>>
>> Steve
>>
>>
>> --- In MAXIMO@yahoogroups.com, Kevin Wertz <wertzee@...> wrote:
>> >
>> > Well I created a companion row in my new table for the attribute where I
>> > was trying to click the checkbox, and it worked.
>> >
>> > So I guess I just have to create rows in my new table for all my current
>> > attributes, then create a trigger that creates a new row in my new table
>> > every time I add an attribute? If there's a simpler way to do this I'd
>> love
>> > to know.
>> >
>> > KW
>> >
>> > On Mon, Jul 2, 2012 at 4:29 PM, Kevin Wertz <wertzee@...> wrote:
>> >
>> > > I think you're right, seems like a better approach, no reason for
>> those
>> > > columns to have to be in the master. So I tried that, created a new
>> object
>> > > with the few attributes plus maxattributeid, created a relationship
>> to the
>> > > new object/table maxattibuteid=:maxattributeid, then added the new
>> checkbox
>> > > from the new object to the database config's attribute details
>> section.
>> > > When I click the new checkbox (which appears editable), I get a
>> message
>> > > that the new object is read-only. Any ideas? I'm guessing Maximo
>> can't just
>> > > create the new row in my new table just because I clicked the
>> checkbox from
>> > > that table.
>> > >
>> > > KW
>> > >
>> > >
>> > > On Mon, Jul 2, 2012 at 4:37 PM, Chris Lawless <lawlessc@...> wrote:
>> > >
>> > >> **
>>
>> > >>
>> > >>
>> > >> I'd be inclined to create a new table to store the additional data
>> rather
>> > >> than touching such critical tables, do you see any issue why your
>> extra
>> > >> columns need to be in the master table?
>> > >>
>> > >> Chris.
>> > >>
>> > >>
>> > >> On Jul 2, 2012, at 14:11, "kevwertz" <wertzee@...> wrote:
>> > >>
>> > >> > Hi I was wondering if anyone has tried and had success with
>> creating a
>> > >> script to add attributes to maxattributecfg. I went to create two
>> > >> attributes: one to indicate whether the user has altered an out of
>> box
>> > >> attribute (user will click upon first edit), and another for comments
>> > >> related to the change(s).
>> > >> >
>> > >> > Of course maxattributecfg is marked as internal so we are not able
>> to
>> > >> add attributes from the front-end.
>> > >> >
>> > >> > Kevin Wertz
>> > >> > Grifols Therapeutics
>> > >> > Clayton NC
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>> >
>> >
>>
>>
>>
>
>