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.
Related
i am using apex application and i want to migrate my application from onw workspace to other.
All my tables ,functions, views etc are moved except application roles which are assigned to users(apex_appl_acl_users). anyone help me for this issue ..
The users are not part of an application, they are part of the individual deployment. You wouldn't want your development users to be exported to production every time you deploy a new version. The solution is to manually export and import the users. There is an excellent blog explaining how to do it here: https://seanstuber.com/2019/06/06/extracting-apex-access-control-users/
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
I have build custom Module in SugarCRM and added a custom field of type 'relate' and linked with Accounts module.
When I insert new record for this custom module via normal add/edit view it works perfectly alright and I can select an account via Account Name field. However when I use Import feature via CSV file it does not link with Accounts module however the Account already exists with same name. Same Account Name is working for other modules during import.
I am working on SugarCRM 6.5, I have build Custom Module via Module Builder than added custom field via Studio and also I have Many to Many relationship with this custom Contacts Module and Accounts Module.
Any help in this regard will be appreciated, I am new to sugarCRM so do not have much of experience and have spent lot of time already to figure this out.
I am working on some Oracle APEX Plugin development and wonder whether the following requirement is possible.
I basically would like to be able, via a plugin, create a form with say six page items, where two of those page items might be LOVs, another two are page items are text fields, where users have to enter values and the remaining two are display items only.
Based on this form requirement, I want to be able to upload/install this plugin within other Oracle Application Express apps/schemas, so when installed within other apps, this plugin is rendered within a region and the data is stored within a table in that schema, but using the form described above.
Can this be achieved building a plugin in Oracle APEX, and if so, how?
Create a stock application with the pages and regions that need to be replicated, export that, and import it into the other workspaces that need it. Then, when developing an application, copy the regions and/or pages as necessary from that stock application.
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... :-)