Engineering Change Request (ECR)

Targeted milestone: 1.2

This document describes how Engineering Change Requests (ECR) could be implemented in openPLM.



  • Who will use it?


  • Does it concern all users? only new users? power users?

Power users

  • May it disturb other users ?

ECR may be too complicated for a new user and some companies may not need such functionality.


  • What does it do?

An ECR describes a request to change one or more parts and documents. ECR are generally created to request a change on official/in production parts.

An ECR is an object with:

  • a reference (ECR_XXXX)
  • a name
  • a description

An ECR is bound to one or several parts or documents.

An ECR has a lifecycle and can be approved (in one ore several steps) or rejected. Generally, when an ECR is approved (officialized), an EngineeringChangeOrder? (ECO) is created. An ECR lifecycle does not have a deprecated state, its last state is its official state.

  • Is it a new independent feature?

ECR will be implemented as an optional application and it should be possible to disable the application without breaking openPLM, even if ECR have been created.

  • Does it replace something?
  • Does it change something?

ECR+ECO may change how a new revision is created. In OpenPLM it will not replaced the simple revision system (the current revision page with one form).

User interface

New pages

ECR pages have 4 tabs:

  • attributes
  • lifecycle
  • history
  • part doc cads

Attributes page

Like the other attributes pages.

History pages

Like the other history pages

Lifecycle pages

Similar to plmobject lifecycle page. Examples of lifecycles :

  • Create => Evaluate => Analyse => Review => Plan modification => Complete
  • Create => Impact Evaluation => Change Order => Complete
  • Create => Change Order => Complete
  • Create => Propose => Technical Analysis => Advices => Modification => Complete

Changes tab

A new tab on each plmobject listing existing ECR bound to the object.

Updated pages

Implementation details

ECR will be implemented in a new application named ecr (should not conflict with an existing python package)

New dependencies


Specifications, standards

Database schema

ECR are similar to PLMObject and share some attributes (name, owner, creator, ctime, mtime, state).


  • ECR do not have a revision field
  • ECR have no group field
  • ECR have no subclasses
  • their lifecycles are different (an ECR can not be deprecated)

The model (ECR) could inherit from PLMObject to reuse all models bound to a PLMObject (`PLMObjectUserLink, History, PromotionApproval...) but this has some drawbacks:

  • some part of the current code does something like
    if obj.is_part:
      # part stuff
      # document stuff

(it could be an occasion to clean up the code)

  • it will be more difficult to disable/enable ECR: For example, the user's part-doc-cad page lists objects using the plmobjectuserlink model and so it could returns deactivated ECR.
  • Promotion rules may evolve in an incompatible way (in bulk promotion and ECO)
  • ECR may not required all stuff (group, revision) -> do not waste memory and space

New models

ECR (Model):

  • reference (unique)
  • reference_number (hidden)
  • owner
  • creator
  • name
  • description (not empty)
  • state
  • lifecycle


  • ecr
  • plmobject

Duplicated models (s/plmobject/ecr)


  • ecr (forein key)
  • user


ECRPromotionApproval (Link)

  • ecr
  • user
  • current_state
  • next_state



A new controller, ECRController.

Views and URLs


current attributes view


current history view


could be the lifecycle view if ECRController provides some aliases (plmobjectuserlink_plmobject, ...)


new function, template can be a copy/paste of groups/objects.html


new function, GET (form) and POST requests


new function, only POST request

/ecr/{reference}/navigate/ and ajax version



Since ECR does not inherit from PLMObject, more work is required to integrate the ecr application with openplm.


The type form (search and create) must know that ECR exists. A quick solution: add a new interface (IObject) and let ECR implement this interface:

Methods of IObject:

  • get_creation_fields
  • get_modification_fields
  • attributes
  • menu_items

The creation form can be easily registered with plmapp.base_views.register_creation_view

If IObject is implemented, ECR can be "search" but not indexed... Simple solution:

  1. create a ecr.search_indexes module
  2. import the module inside
  3. add a hack to plmapp.search_indexes to import applications search_indexes if rebuild_index is called


It would be nice to browse ECR:

  1. handle the url {browse}/ecr/
  2. in plmapp.browse: add IObject subclasses