Moving custom fields from quote to project XTRF Client Portal API - xtrf

I have a problem with moving Custom Fields from quote to project.
Quotes are created via Client Portal API and as far as I know theses quotes are classic ones. When I create project from classic quote, project doesn't populate custom fields.
I tried to update project manually with quote's custom fields.
Everything I have is classic quote with numeric id. I extracted idNumber from quote, and searched for project using with method https://prisma.s.xtrf.us/customer-api/doc/pages/projects.html#GET_/projects and adding ?search=quoteIdNumber.
Then I received project created from quote.
I tried to update project's customFields manually from quote's customFields, but I didn't succeed. I extracted projectId from received project and tried this method https://prisma.s.xtrf.us/api/doc/users/pages/v1-projects.html#PUT_/projects/{projectId}/customFields to update project's custom fields. I received error that I am trying to update Smart Project and I should use newer API, but V2 API for Smart Projects requires different project Id than I received. I received project id like this 576, but updating smart project requires id like this ABCDEFGHIJKLMNOP.
Is there a way to move custom fields from classic quote created via Client Portal API to new smart project created from that quote?

Have you tried using different custom field scope?
What I mean is a scope where custom field is shared between quote and project.
See picture

Related

Azure DevOps: Field with default value containing another fields value

I am trying to find a way in Azure DevOps of displaying a field on a User Story layout that is made up of a URL plus the value of another field on the same story.
We have an external support ticket system where all of our support calls are logged. When the story (or even Defect) is created, we have a field where a support reference is entered.
I want another field that combines a URL and the support reference so it creates a link to the support ticket.
Is this do-able?
Thanks,
Craig
This is achievable. You can Add a custom field to a work item type for an inherited process.
1,First you need to create a inherited process.
Go to Organization settings, From the Process page under Boards, open the … context menu of the process you'll use to create an inherited process, and then choose Create inherited process. Choose the same system process—Agile, Basic, Scrum, or CMMI—that was used to create the project that you want to customize.
2, Add a custom field to an existing work item type for the inherited process.
From the Process page of the selected inherited process, choose the work item type(User Story) you want to add the custom field to.
Select the work item type and click new field or ... to add a field under a group.
For example i add a new field Support Url under group Planning(click Options to define a default value for this field).
3, Apply the customized process to your project.
Click team projects of the process shown as below screenshot.
Open the … context menu for the process and choose the Change team projects… option.
Then you will have the custom field with default value for the work item type in your project.
For detailed steps please check Microsoft Document there.
Update:
Field value made up of a static part, plus another field
There is no direct way or any tool i can find to achieve this. However there is a complicate workaround to achieve this.
You can try creating a service server to to combine the field values and update the workitem field with workitem update rest api, and add a service hook to this service server.
You can refer to the service hook sever provided by Microsoft. Check reate a pull request status server with Node.js

How to default field based on project-level settings in Azure Devops?

I need to set a field on all User Stories, and that field will be the same for all stories within a project. Namely, I'm trying to assign projects to certain Project Leads and I want them to be defaulted as the Project Lead on all the user stories withing that project. How do I create a rule that will default a custom identity field to be the same for all user stories within that project? I'd rather not create a new Azure process for each new project. I want to be able to manually set some field on each project at the project level, and then have the default on my custom field in user stories within that project to be based on that project-level setting.
Currently this can't be done through process customization. Unless you create a custom process for each project.
The Aggregator-CLI can process a rule after a work-item is created/updated and you can use it to set these default values based on a lookup.
This one-click extension also makes it possible to run rules on the workitem form itself. It takes a different approach (runs in UI instead of from a servicehook).

IBM create automatically children work items

I work in IBM RTC (Rational Team Concert); the Project Area I own is built on the IBM Formal Project Management Process Template.
I’m looking for a mean to get work items created programmatically;
I do want when I create a Change Request work item, to allow the selection of different teams and from this attribute(s), create automatically children work items Task directly assigned to the right team/member.
How would you recommend to do so?
Although it is not a direct answer to your issue, but I guess it would help. It's more like a workaround more than a solution to your requirement.
The work around is divided into two steps:
Create a work item template from a CR with all its sub tasks included in the work item template.
Create a CR using the previously created template programmatically.
Note: This means that you'll need to create a work item template for each team.

is it possible to get an xPages build number?

I do all development in a single application. when a new version is ready I create a template and give it a version number. this way I can store a history of all previous versions.
the development templates are used to push the new design to many applications via replace design.
Creating manual version number or template names is fine but I am looking for a more automatic way of finding out which build the different applications are inherited from
When I visit the different applications I would like to be able to see which build number each application are inherited from. is this possible?
A simple build time stamp could do, but is there a built in build number that can be used and that can be displayed on the xpage.
e.g Build 2012092712345
Update:
Thank you for all your answers, many good suggestions but it looks like all require manual work.
The best solution would be if there is a way to read (from ssjs) a timestamp from any file within the nsf that is always updated during a build. is this possible?
In classic notes, there was a method to add a shared field with a special name to the application. Cannot remember the details, but have it somewhere on the disk.
Then you can see the build number in the design tab of the application properties. And you can of course display the value in your applikation as well.
But you have to fill the item manually on each build. Or use teamstudio Buildmanager. This tool adds the value automatically.
And I also guess that you can write some code that changes the value whenever you create a new build.
Another option would be to use a versioning system like CVS/SVN. This is possible since 8.5.3.
Source control
I think I know what you are meaning. Your a pushing out design and want to check thru code what version each database has. I usually do this with a Build form. In this form I have computed fields with all the data I want to retrieve. Then I open the database with an agent create a document
and set the form field to "BuildForm" and do a computewithform.
Now I can see all information about this database.
I once wrote a rudimentary build system for "classic" Notes, and had the last part of the build pipeline create a form named _BUILDID_, and put the build id in the $Comment field.
The main reason to create a form instead of a shared field was that I could dynamically fetch the form using NotesDatabase.Forms, and open up the desired field.
I sure hope there are simpler solutions nowadays... :-)

Deploying Salesforce packages - will custom fields included in package overwrite target orgs fields with same name?

I'm relatively new to Salesforce, so I my be missing something basic here:
There is an existing Enterprise site. It has a number of custom fields (i.e. Account.MyCustomField__c), pages and of course lots of customer data. As far as I can tell it was all setup from within the Salesforce instance itself (no custom Apex code or special packages)
I want to add an Apex class to this - a tiny Schedulable class with a few lines of code to select and update one of those MyCustomField_c fields on a few records each day. To do this I signed up and created a developer site and manually recreated the MyCustomField_c (same name, API name, label, type, etc) and then created the class and it's test methods.
Now here is my concern:
When I go to create a package so that I can copy this class to the Enterprise site the custom field shows up as a dependency that will be automatically included in the package. What happens if I install this package - will the duplicate field be added/overwrite the existing one, or cause an error? Ultimately I want my apex class to use the field already in the Enterprise site of course.
Alternatively, is there some way to export the custom fields/setup from an enterprise site into a developer site, so that the resulting packages from the developer site will already take into account dependencies that are present in the enterprise version?
Are you moving the code as a packaged app (with a namespace) or via change sets? Generally we do deployments using Eclipse — we don't package things up so don't use namespaces.
The simple version is: if you're not using a namespace and a packaged app then your code should use the field that's there. If you are using namespaces, your field will automatically be created in the target org with a prefix, as such it will be a different field to the one that's there already.