I say that is correct Pro/INTRALINK behavior. You promote objects to
Released ? a milestone- but you should still be able to continue to modify
them (technically now an ECO), and to submit them.

However, you can use INTRALINK standard functionality to pull off your
objective:
- Remove the rights to demote  a n d  to drop release level in workspace;
an object will thus be stuck at Released.

A more sophisticated procedure:
- Introduce a third Release level, say Draft2 or ECO, that you drop
released objects to in WS, and allow users to drop to that release level
only. Also block promotion from Draft to ECO. (Note: sequence must be
Draft - ECO - Released  for this to work.)
- Baseline released objects (optional)
- Use display filters and Locate custom searches that only show objects at
a Released level (and/or only open released data to users other than
engineers/designers)

Johannes Klein
Teradyne Connection Systems

charlie.sears@radiusdevelopment.com@ptcuser.org on 06/27/2003 09:53:09 AM

Please respond to charlie.sears@radiusdevelopment.com

Sent by:    bounce-datamgt-18096@ptcuser.org


To:    "datamgt" <datamgt@ptcuser.org>
cc:

Subject:    [datamgt] Revision and release levels


I was asked to post a summary of my replies to the following situation:

It has recently come to my attention that it is possible for the following
sequence of events to occur within Intralink.
1)    revision 1, version 0, release level draft
2)    revision 1, version 1, release level draft
3)    revision 1, version 2, release level released (view only permissions,
release level changed through promotion)
4)    revision 1, version 3, release level draft (release level changed in
the WS)

So.. the released revision has been superceeded by another PIV.  Is there
anyway to prevent the checkin of the same revision of an object once a
specific release level has been set?  Once an object has been released at
a specific revision, I do not want any new versions of that revision
checked in to the CS.


A lot of replies indicate I am not alone in thinking this is an insane
situation.  Apparently this situation is by design.  The only solution
that I know works is to go to www.frotime.com, register and download a
free trigger that prevents checkin of a new PIV if the release level of
the object in the CS is "Released".

Hope this helps,

Charlie