Community Tip - You can change your system assigned username to something more personal in your community settings. X
Hello,
in order to support a "trivial change" (ex: correct the description of released object), we are willing to programmatically create a new iteration of EPDMDocuments (resp. WTParts). This has 2 targets
The first attempt was to checkout/checkin the "released" iteration, but for some older data, some attribute values are not allowed anymore by the datamodel and we get an EPMNonOverrideableConflictException during the checkin operation...
Creating iterations directly seems not to be supported by PTC, The PersistenceManager store the iteration with a new creation date (instead of using the creation date of the revision).
Does someone already has a similar case ? Or an Idea how we can handle this use case ?
Solved! Go to Solution.
Hi @lmouchard
Creation date is a revision creation. So this should not be changed if you create new iteration.
You may do something wrong during the creation by code.
Iteration can be created. There is no limit expect ACL rules. As an admin you can create new iteration without any trouble and also the API works as I would expect.
Creation date = date when the revision has been created
Modified date = date when the iteration has been created.
So describe your case more deeply I would also like to see the screen with the creation and modified dates before a check-out and after check-in.
Also share your code.
PetrH
Hi @HelesicPetr,
I do totally agree your analysis, that is the reason why I am stuck... I could not figure why Windchill set a new creation date.
Here is a sample of code used:
/**
* create new iterations for the targets of the promotion notice. This is done
* without checkout/checkin, because it would not work for older data, some
* attribute values are not valid anymore.
*
* @param wtCollection
* @throws WTPropertyVetoException
* @throws WTException
*/
public static WTCollection createNewIterations(final WTCollection wtCollection)
throws WTPropertyVetoException, WTException {
if (wtCollection == null || wtCollection.isEmpty()) {
// LOGGER.debug("empty collection, skip createNewIterations...");
return wtCollection;
}
// Makes a new iteration/version as a copy from the given one
// LOGGER.info("Creating new iterations for Trivial Change...");
WTValuedMap newIterations = VersionControlHelper.service.newIterations(wtCollection, true);
// indicate the promotable is not the latest version anymore and increment the
// iteration id
// LOGGER.info("Supersede the new iterations...");
newIterations = VersionControlHelper.service.supersede(newIterations);
// LOGGER.info("Store the new iterations in Windchill...");
final WTCollection persistedNewIterations = PersistenceHelper.manager.store(newIterations.wtValues());
return persistedNewIterations;
}
Actually, there is a store method in the StandardPersistenceManager that takes the creation and modification timestamp as input param, but I could not manage calling it (because PersistenceHelper.manager does return a Proxy instead of the implementation)
Thanks @HelesicPetr, it looks great with this server helper.
I tested with the PersistenceServerHelper.manager.store method (as it is tagged a public API), and it seems to do the job! I still have to adapt my code to manage the individual objects instead of collection... let me some days for checking and I'll mark your answer as solution ;).