Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Help needed adding new columns to Impact matrix #4

Open
sachinbijadi opened this issue Dec 3, 2018 · 10 comments
Open

Help needed adding new columns to Impact matrix #4

sachinbijadi opened this issue Dec 3, 2018 · 10 comments

Comments

@sachinbijadi
Copy link

I am trying to add effective date columns for old and new change controlled items in the impact matrix.
I added a row in the table grid initiation and then defined a new class for it. However I get empty cells in the matrix even though the items in the list do have effective dates. Any help on this?

image

image

image

@sachinbijadi
Copy link
Author

I corrected the text to "effective_date" from the wron "efffective_date" still same issue. When I did the same for the New item's effective date, that works just fine.

@AngelaIp
Copy link
Owner

AngelaIp commented Dec 5, 2018

Tell me what´s behind your Summary, MBOM and Process Plan tab in your Part, and I will check my Impact Matrix for how I did this one. Impact Matrix may also require codetree modifications.

You don´t have to provide detailed pictures, just one/two sentences about what you do there. As a person who also uses MPP, I am interested to see how how others use this applicaiton!
I was always thinking about adding an MBOM tab to the Part just like you did. But I wasn´t sure about the content I want to show the users (tree grid view?).

@sachinbijadi
Copy link
Author

Summary tab is basically a TGV based on the TGV demo by Aras, which shows child parts, linked cad and docs, AML parts & alternates, and process plans where the part is the producedpart or a consumedpart.
MBOM tab is also a TGV that shows the MBOM of the part (i.e in the process plan for the part, all the consumed parts in that PP are listed in the TGV)
Finally, Since PP has a hard fixed relation with part (mpp_ProcessPlanProducedPart), I added a new relationship from Part to its linked processes (with a float relation), so that the PP can appear in teh Impact matrix to indicate that if i modify teh Part, I might have to update the PP (depending on the ECO details) (Background, I have added mpp_processplan to Change controlled item and change controlled relationship to make it appear on the Impact matrix)

@AngelaIp
Copy link
Owner

AngelaIp commented Dec 5, 2018

Have you already tried to write efffective_date without three f?

@sachinbijadi
Copy link
Author

Yup.
It works just fine when used for new version item (i.e new effective date)

@sachinbijadi
Copy link
Author

image

@AngelaIp
Copy link
Owner

AngelaIp commented Dec 5, 2018

Ok, it´s too late for me today for ImpactMatrix questions. But maybe it´s related to the properties in Affected Items. I remember that I use foreign properties to display certain informations.

var customprop = this.grid.getProperty(this.row.data.affectedItem, "customprop");

@AngelaIp
Copy link
Owner

AngelaIp commented Dec 5, 2018

One last comment for today. What behavior do you see, when you perform multible Express ECOs at the same Part? For example if you change the Major REvision 5 times. Is your previous Item in older Express ECO floating to the latest verison of the Part or does it stick to the original generation?
This one was making me quite a headache in the past, as it was acutally impossible to track changes with the Express ECO.

@sachinbijadi
Copy link
Author

sachinbijadi commented Dec 6, 2018

It floats to the latest version, if the eco is still before in work stage. Once past it stays fixed. I have not made any edits to the ECO lifecycle as far as the states' beahvior goes. On the older completed ECOs, the generation remains fixed. I had the floating issue with the Simple MCO, that it would point to the latest generation. so there i modified the lifecycle of the mco to have a fixed release state, so that once released, it will stay pointing to the the generation of the part when released. It is a bit dangerous to play around with the behavior of the states, but I am trying to set up minor-rev handling for simple changes that involve any engineering impact (like associated info on a form, etc.) so i modified the MCO to act like a Minor change order process with permissions to certain teams to modify specific info when the MCO pushes the part to the Manual CHange state

@sachinbijadi
Copy link
Author

Also we learnt to bunch our changes in Express ECOs in a careful way that we tried to limit parallel changes on teh same part. Our Product is extremely systematically complex, with way too many interaction between subsystems, that if we touch one, we will have to change a lot of parts. So we are using the ECO just as a documenting board for the impact and final recording of the actual changes. THe PMO handles the complete workflow and not the designers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants