I have migrated my local TFS project to TFSO. Unfortunately I could not use the OpsHub migration tool because the language of the local instance was German and therefore the work-itemscould not be transferred. I have introduced a lot of references to work-items in source-code. The problem is that now the ids starts with 1, resulting in references from code to work items that are not related.
Is it possible to set the ID in TFSO to a specific number in order to have newly created work-items to start with that number?
No, there isn't any way to changeset or specify the Work Item ID. It is controlled by VSTS.
And the reference link between the changeset and workitem is stored in the workitem. So if the you haven't migrated the work items, don't worry about the incorrect reference for the code and work items.
Related
If I create a work-item in project 1 with id 100 then the next work-item would be 101 if I create another work-item but in project 2. I need work-item id 100 in project 1 and work-item id 100 (or whatever) in project 2. Is that possible?
Can I have work item auto-id numbering separated by project?
For this issue,I think it is impossible to make work items automatically numbered in their respective projects. Currently this is designed like so.
The scope of our work is an organization, sometimes we will need multiple projects to work together, so the id of the work item is applied to the entire organization. If there are workitems with the same id in different projects, then we will be confused when we query work items across projects.
In addition since work item ID is unique identifier which is assigned by system, so we can not custom the work item ID when creating a work item. You can refer to this official document.
The unfortunate answer is: no.
The reason lies in the fact that the work item ID is also used as the single unique identifier to link work across projects in the same project collection (on-premise) or organization (cloud). Hence, the number must be unique in the whole collection.
There have been multiple attempts in the past to separate projects and the identifiers. All have met an untimely end due to the complexity involved and backwards compatibility concerns.
If I create a work-item in project 1 with id 100 then the next work-item would be 101 if I create another work-item but in project 2. I need work-item id 100 in project 1 and work-item id 100 (or whatever) in project 2. Is that possible?
Can I have work item auto-id numbering separated by project?
For this issue,I think it is impossible to make work items automatically numbered in their respective projects. Currently this is designed like so.
The scope of our work is an organization, sometimes we will need multiple projects to work together, so the id of the work item is applied to the entire organization. If there are workitems with the same id in different projects, then we will be confused when we query work items across projects.
In addition since work item ID is unique identifier which is assigned by system, so we can not custom the work item ID when creating a work item. You can refer to this official document.
The unfortunate answer is: no.
The reason lies in the fact that the work item ID is also used as the single unique identifier to link work across projects in the same project collection (on-premise) or organization (cloud). Hence, the number must be unique in the whole collection.
There have been multiple attempts in the past to separate projects and the identifiers. All have met an untimely end due to the complexity involved and backwards compatibility concerns.
I'm developing a system with database version control in LiquiBase. The system is still in pre-alpha development and there are a lot of changes that were reverted or supplemented by other changes (tables removed, columns added and removed).
The current change set reflects the whole development history with many failed experiments, and this whole is rollouted when initializing the database.
Because there is NO release version, I can start from scratch and pull actual DB state in single XML changeset.
Is there a way to tell LiquiBase to merge all change sets into one file, or the only way to do that is per hand?
Just use your existing database to generate change log that will be used from now on. For this you can use generateChangeLog command from command line, it will generate the changelog file with all the changeSets that represent your current state of the database. You can use this file in your project as initial db creation file, to be used on an empty database. Here's a link to docs.
There is a page in the Liquibase docs which discusses this scenario in detail:
http://www.liquibase.org/documentation/trimming_changelogs.html
To summarise, they recommend that you don't bother since consolidating your changelogs is both risky and low-reward.
If you do want to push ahead with this, then restarting the changelog using generateChangeLog, as suggested by #veljkost, is probably the easiest way. This is documented at http://www.liquibase.org/documentation/existing_project.html
Hence I didn't find automatic solution for this problem in case the changelog is already deployed on several databases in different states, I will describe here my solution for this problem:
Generate changelog of your current development state of database using liquibase generate changelog, like:
mvn liquibase:generateChangeLog -Dliquibase.outputChangeLogFile=current_state.yml
Audit generated changelog, check whether it looks good (liquibase is not perfect, it often generates stupid statements). Also if you have in your schema some static data, like dictionaries or so, which were previosuly populated using liquibase, you have to add these to generated changelog as well, you can export data from your database using generate changelog command mentioned above with -Dliquibase.diffTypes=data property.
Now to prevent the execution of generated changelog (it will obviously fail on existing databases, on prod, test, and other developers local envs), you can do this using for example liquibase changelogSync, or using liquibase contexts, but all this options require you to do some manual work on every database. You can achieve automatic result by adding the preConditions statements for your changeSets.
For changesets intended to run on empty databases (changelogs you generated in step 1. above) you can add something like this:
preConditions:
- onFail: MARK_RAN
- not:
- tableExists:
tableName: t_project
Where t_project is the table name that existed before (most likely this should be table added in first changeSet, so every database which runned at least one changeSet will have this). This will mark generated changelog as run on environments with existing schema, and will run generated changelog for every new database you would like to migrate.
Unfortunatelly you have to adjust all legacy changesets as well (I didn't found better solution yet, I did this change using regex and sed), you have to add something like that:
preConditions:
- onFail: MARK_RAN
- tableExists:
tableName: t_project
So opposite condition, from above one. With this all databases which runned at least one changeset in past, will continue to migrate (EXECUTED status of changesets) until changeset generated in step 1. above, and mark generated changesets with MARK_RAN. And for new databases, all previous changesets will be skipped, and first executed will be one generated in step 1. above.
With this solution you can push your merged changelog at any time, and every environment and developer won't have any problem with manual syncing or so.
I am trying to create custom build version number.
We already using some custom build template and have created custom activities. Now I am trying to add custom build version activity in our template.
My idea is to select last build and extract only number which represent number of builds. This is last digit and it can be e.g. 5.2.3.1032 (marked as bold).
Based on last digit I will create next build number and insert into TFS database.
I can also use UpdateBuildNumber activity to insert number, but is there way to select build number by querying TFS db directly? It is also good if is possible via PowerShell.
Thanks
It sounded familiar, in fact I wrote a post on this topic a while ago. Probably the code and details must be reviewed to work with recent TFS, but the general idea is still applicable.
At the core you use the IBuildServer.QueryBuilds method to read your build history and pick the information you need.
Is there a way to detect that a record being inserted is the result of a clone operation in a trigger?
As part of a managed package, I'd like to clear out some of the custom fields when Opportunity and OpportunityLineItem records are cloned.
Or is a trigger not the correct place to prevent certain fields being cloned?
I had considered creating dedicated code to invoke sObject.Clone() and excluding the fields that aren't required. This doesn't seem like an ideal solution for a managed package as it would also exclude any other custom fields on Opportunity.
In the Winter '16 release, Apex has two new methods that let you detect if a record is being cloned and from what source record id. You can use this in your triggers.
isClone() - Returns true if an entity is cloned from something, even if the entity hasn’t been saved.
getCloneSourceId() - Returns the ID of the entity from which an object was cloned.
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_getCloneSourceId
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_methods_system_sobject.htm#apex_System_SObject_getCloneSourceId
One approach, albeit kind of kludgy, would be to create a new field, say original_id__c, which gets populated by a workflow (or trigger, depending on your preference for the order of execution) when blank with the salesforce id of the record. For new records this field will match the standard salesforce id, for cloned records they won't. There are a number of variations on when and how and what to populate the field with, but the key is to give yourself your own hook to differentiate new and cloned records.
If you're only looking to control the experience for the end user (as opposed to a developer extending your managed package) you can override the standard clone button with a custom page that clears the values for a subset of fields using url hacking. There are some caveats, namely that the field is editable and visible on the page layout for the user who clicked the clone button. As of this writing I don't believe you can package standard button overrides, but the list of what's possible changes with ever release.
You cannot detect clone operation inside the trigger. It is treated as "Insert" operation.
You can still use dedicated code to invoke sObject.Clone() and exclude the fields that aren't required. You can ensure that you include all fields by using the sObject describe information to get hold of all fields for that object, and then exclude the fields that are not required.
Hope this makes sense!
Anup