This is likely due to your ‘Multi Row Update Mode’ import preference.  This should be set to “Add/Update Only” (default is “Complete Replace”) in order for the import wizard to update existing component attributes rather than completely replacing the component with a new line.

This is likely due to your ‘Multi Row Update Mode’ import preference.  This should be set to “Add/Update Only” (default is “Complete Replace”) in order for the import wizard to update existing component attributes rather than completely replacing the component with a new line.  
Import Preference > Business Rule > Multi Row Update Mode

You could just set up an advanced search based on the Pending Change.Number or Change History.Number and modify the output format to include the Title Block attributes you are looking for.  This will return a separate line for each affected item that is on that change and then you can just export the results.

Advanced Search –
Items – Parts – Object Search
*Pending Changes.Number – Equal To – [Change Number] 

*use Pending Changes.Number if the change in question is has not yet been released else use Change History.Number.  You could also just add an OR statement if you don’t know the status of the change.

Just one thing to note –
If you have multiple approvers responsible for populating different required fields (or maybe some reviewers are responsible for populating data and some are not) in the same status – going about it this way would likely prevent some approvers from approving even if their portion IS complete/populated.   This can lead to things being held up even longer as most users don’t want to have to be constantly checking on the routable object just to see if they are able to approve it yet. 

If/When this is the case – I think it is best to leave it to the routing manager to sort it out.  Upon receiving the ‘auto-promote failure’ notification – the routing manager should run a status audit to see what is missing and then contact the appropriate reviewer to populate the missing information.

It also helps to train users to get in the habit of always running a status audit prior to approving, though that is not at all fool-proof.  
 

An admin could also just enable the relationships tab for the object type.

– Java Client > Admin > Data Settings > Classes 
– open appropriate object type (ECO or Discussions)
– under “User Interface Tabs” Tab – open “Relationships”
– set “Visible” to ‘Yes’

Hold and Cancel are special status types that are not visible unless you have the appropriate Change Status privilege(s).

This is configured in the Java Client under Admin > Server Settings > Database

Notification Enabled: Yes (if set to ‘No’ all other email notification properties are ignored.)
Mail From Domain: [domain for email notification] ex. yourdomain.com
Mail From User: [the “from” email address for Agile email notifications] this needs to be a valid email address. ex. Agile@yourdomain.com
Mail Server External: [name of computer running external email server]
Mail Server Internal: [name of computer running internal email server]

I would recommend just modifying your discovery privileges/criteria to not include the obsolete parts that the users don’t want to see.  That way you don’t have to worry about unreleasing anything (which can be risky itself) in order to soft-delete nor would you be in risk of breaking any associations to workflows, change objects, etc…

If there are some Obsolete parts they do want to see and some they don’t – you could just create some new page2 attribute that could be used to differentiate the two situations.  This could be used in your discovery criteria.  Something like Discover Valid Parts (Part Objects where Page 2 “Valid” is not “NO”).

Once you have all of the invalid parts marked (which can be done via import if you leave it not change controlled) you can simply hide this attribute to avoid confusion and/or anyone marking items invalid that shouldn’t be.

You can import BOM and AML data at the same time by using the “Level Template” option after you select your source file in the import wizard.  The Import/Export User Guide lists required columns that your source file must contain in order for this to work and they do need to be exact.  You also need to make sure that all of the Manufacturer Objects already exist in the system (this can also be done through a separate import).

Note – If you are trying to add AML data to existing RELEASED Items – you will need to create an ECO or MCO first and specify the change number as part of the import.  If the existing items aren’t yet released – you shouldn’t need a change to import the AMLs.

Take a look at the “Using Templates to Import Data” section in Chapter 2 of the Import/Export User Guide.  It is pretty straight forward, but if you have any questions – just let us know.

No, not without some extra process extension/validation as modify rights for attributes allow users to add to and remove from any of the “Applied to” fields. 

As a workaround – you could split each of them into two separate attributes that use the same list (“List1” and “List2”, for example) and create a modify privilege for these users that only allows them to modify “List2″ and only IF “List1″ is already populated.