{"id":1539,"date":"2017-05-22T10:03:23","date_gmt":"2017-05-22T09:03:23","guid":{"rendered":"https:\/\/www.threesl.com\/blog\/?p=1539"},"modified":"2017-05-22T09:09:55","modified_gmt":"2017-05-22T08:09:55","slug":"reset-auto-numbers","status":"publish","type":"post","link":"https:\/\/www.threesl.com\/blog\/reset-auto-numbers\/","title":{"rendered":"Can I reset the auto number?"},"content":{"rendered":"

Auto Numbering Change and\u00a0Reset<\/h2>\n

The short answer is yes you can reset an item’s auto numbering. The more complex answer is a word of caution.
\nFirstly to reset the auto number for an item you need ACCESS_BYPASS<\/samp>, or PROJECT<\/samp> project privileges.
\nThis is to prevent any accidental operations by a user.
\nSecondly you should ensure you understand the issue you are trying to resolve and the consequences of resetting in a live database.<\/p>\n

Item Numbering<\/h3>\n

Every item in the database has a unique identity made from a combination of attributes. These usually include the Identity,<\/em> Version<\/em> and Draft<\/em>. Model based information includes the Domain<\/em> and MUID<\/em>. The identity can be manually entered or automatically filled. There are benefits to both. For example; if your customer sent you a set of user requirements in a CSV file, you would want to retain whatever ID system they had used UF1.45<\/em> to UF6.78<\/em> having a Cradle Auto ID<\/em> and then having to place their ID in the Name<\/em> field would make little sense. On the other hand when raising a new Issue, you’d expect them to be sequentially numbered without having to find the previous item and mentally add ‘1’ and type into a field.<\/p>\n

When Values Need Resetting<\/h3>\n

In the case where a batch of items have been imported or created, but whilst at draft a decision has been made that none of them are required, or are fundamentally wrong, they would normally be deleted. The next item to be created would then have an auto number of say “Res-103<\/em>” which may not be appropriate. In this case resetting the count <\/a>for the “Result” item type makes sense.<\/p>\n

When Values Need Setting<\/h3>\n

It is possible that batches of requirements come in from various sources, it may be convenient to start each batch at a ‘nice’ number point “Reference-1 … Reference-560<\/em>” and then “Reference-1000 … Reference-1304<\/em>“. In this case setting the number<\/a> by advancing the count would be appropriate.
\nIf new versions of the item were brought in by import expecting to overwrite the old ones, and the user forgot to mark “Ignore project’s current auto numbering<\/em>” you would end up with two versions of the item. In that case 1..n<\/em> and n+1..2n+1<\/em>, deleting items n+1<\/em>..2n+1<\/em> and choosing “Set Highest<\/em>” would return the database to the point before the mistake.<\/p>\n

When Caution Should be Exercised<\/h3>\n

Once the items are stored in the database, their Identities should remain fixed. Creating a new version of an item would normally involve the original version being baselined, a Change Request<\/em> <\/a>being raised and a Change Task<\/em><\/a> being issued to allow the work to create the next draft version of the item. In this case the identity remains the same but the two versions of the item are unique by their Version and Draft. Changing the auto number when there are items in the database and then creating new items of that type would cause conflict with items already stored. This is not a desirable effect. Therefore, the message is be careful, this feature is necessary and useful in some cases but incorrect use could have undesirable side-effects.<\/p>\n

\"showing
Auto Number Reset<\/figcaption><\/figure>\n