How to prevent user from manually changing release field on drawing

[silardi]

On our standard drawing format there is a table cell that shows release level (WIP, check, release) through a relation to the life cycle parameter.  I recently had a case where a user bypassed the tool administrator by breaking the relation to the life cycle parameter and simply writing "Release" in the cell.  Is there a way to prevent a user from modifying cell contents either through password protection or permissions in CREO?

I'm using CREO Parametric 2.0

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[TomU]

Ultimately, no.  You can slow them down though...  Some things to try:

• Place the a note to the life cycle parameter directly on the format.  This won't be editable from a drawing (only from the format.)
• Consider using a single cell repeat region in the drawing table.  This is not as easily overwritten.
  

[TomD.inPDX]

Any pro|program tricks that can throw a user a curve ball?

I remember something like that stopping someone dead in their tracks before.

[TomU]

None come to mind.  Again, the issue is not the value of the parameter, it's whether or not that parameter is still being displayed on the drawing.

[lhoogeveen]

Tom,

How do you link the lifecycle parameter (&ptc_wm_lifecycle_state) though a format of the drawing through a note? Won't it just reflect the Format parameter instead of the Drawing parameter? I would be a big fan of this functionality as it would let admins update all drawings quickly and easily if there was ever a change to the standard drawing format as well as getting rid of a lot of tampering. We left our company logo as a symbol on the format for that same reason. I did some testing with this but have been unsuccessful as the note doesn't do anything or would link to the format parameter instead of the drawing parameters.

Add a NOTE to the format with the desired parameter...

Notice how it's reflecting the FORMAT parameter value. We've customized our states to have Production rather than Released.

The format note is still reflecting the format parameter not my test drawing.

If that does work, that seems like it would stop most people from tampering with it especially if they don't have access to modify the formats.

We currently stamp our PDF's afterwards to reflect the Windchill states and ECN's but it's not my favorite as people inside of Windchill/Creo don't get to see the stamp. It also required quite a bit of customization.

[BenLoosli]

When you put the &PTC_WM_LIFECYCLE_STATE on the drawing, you need to tell it to pull the value from the drawing: &PTC_WM_LIFECYCLE_STATE:D.

If you want the Lifecycle state of the first model in the drawing, use: &PTC_WM_LIFECYCLE_STATE:1.

[lhoogeveen]

I should've clarified... I tried both &PTC_WM_LIFECYCLE_STATE and &PTC_WM_LIFECYCLE_STATE:D in a Note on the FORMAT but the ':D' gets removed to as soon as unselecting the note.

[dgschaefer]

A point of clarification, the first model in the drawing could be any session ID, not just :1.  Creo assigns the ID based on the order the files are opened.  It also assigns parts an even number and assys an odd number, so :1 would be the first assy opened in that session.  So, if you have an assy of 30 parts open and then start a drawing of one of them, that part could have any session ID from 0 to 58 depending on the order it was retrieved from disk.

[mdebower]

Lucas,  try adding :MDL after the parameter inside the note.   This is supposed to force it to look for the model parameter.   Might help

[TomU]

Lucas is correct.  None of these will work if the parameter is contained in a note on the format.  The ":D", ":MDL", and ":<session id>" syntax is only valid for drawings.  Yes, you can use them in tables on formats, but they won't actually get evaluated until the table is copied to the drawing (when the format is applied.)

[mbonka]

What about restricted parameter in combination with Modelcheck ? --- just an idea

Restricted:

- parameter is restricted to following values: WIP, check, release

Modelcheck:

- each part/assembly have to include your specific relation for "release" else it´s not possible to check-in model

Just an idea

[TomU]

I don't think this will help.  The issue here is not the value of the parameter but rather the removal of the parameter entirely from the table cell (overwritten with plain text.)  The original parameter did not change, it's just not visible anymore.

[dschenken]

If you have users who are willing to falsify their work, then that's a management problem.

For example. If you made it so that the existence of the parameter could be checked for, then I could set the location off the drawing or set the text height to a tiny number or put it on a layer and blank it. After that I just add a text note with whatever I want - or, if that's looked for, by creating an IGS or DXF import of a vector representation of the note.

Whenever the problem is a user going out of their way to do the wrong thing, the correct option is to remove the user from the environment.

[TomD.inPDX]

I've found white e-stickers on PDF master files in PDM.

When you contract detailing work, expect the worst!

Could Model Check look to see if the field/annotation value is the same as the PDM value?

In previous lives, companies have written out release routines where the PDM does the final "stamping" before everything was sealed up in the PDM.

It would stamp the release state per the PDM on the drawing (in the CAD!)*, generate the plot(PDF), generate appropriate export formats, and save all the files to the right locations.

*If you have PDM modify the original CAD file, realize that it has to open as it was last saved.  ref: UGNX/Teamcenter