When I try to deploy a new apex class from a sandbox, I get the follow problems:
SFDCAccessControllerTest testAccessControl_runAs System.AssertException: Assertion Failed: Should not succeed as Survey__c is not accessible to standard user
Stack Trace: Class.SFDCAccessControllerTest.testAccessControl_runAs: line 58, column 1
Utilities_Test getInstance System.AssertException: Assertion Failed: Expected: , Actual: xxxx.
Stack Trace: Class.Utilities_Test.getInstance: line 18, column 1
I suppose it's only a bad configuration, but I'm relative new with salesforce and don't know where I can disabled both test or change permissions for Survey__c and fix the problem with the instance name withouth affect the production eviroment.
I looked for similar cases and could not find it, please can anyone guide me.
Hard to say anything without the test's source code. Do they create a dummy user with "Standard User" profile or try to query existing user? From what I remember you can't edit standard profiles, you have to clone them so I don't know how would you or colleague manage to add Read permission... But check the profile mentioned in the test -> object permissions -> Survey -> read right.
It is also possible to deploy to production without running all tests. It's bit tricky, you need to specify the classes you want to run, you could skip that unit test. But everything you pick need to pass the rules (75% coverage minimum etc). If you need to deploy to prod ASAP it could help but well, you need to eventually bite the bullet and check what exactly is wrong with the test.
Related
We recently refreshed our SF development org and I am trying to upload some new work (unrelated to Agile Accelerator managed package) to the org. I am running all tests on validation and getting a number of error messages on a number of ADM classes from the managed package for Agile Accelerator.
Here are a few of the error messages:
When looking at the object I can't find any field called ProfileId, or any reference to a ProfileId for a User. Obviously since the package is managed I can't get inside the code to determine where the issue lies.
Any help? Any idea of where to start?
You haven't pasted any errors... When you validate, which option you select?
Running all local tests should be enough. don't bother running all tests including managed package ones, it's almost guaranteed they'll fail (when package inserts new account it'll have no idea about your custom fields, your required, your validation rules...)
If you have run local tests and got errors - well, maybe there are few fields package added that now you have to populate to successfully insert? Generally see what successfully saves in UI and try to replicate that in test?
My company hired an agency to create an MQL salesforce object. Its constructed from an Apex class with various triggers.
We no longer have a need for it, and as the standing saleforce admin, there is none at the company who knows Apex. I'm taking classes to learn it, but wanted to check in and see how I can deprecate the object from salesforce by archiving/deleting (or even just commenting out the code) to push the update to production.
Does anyone have insight into how to go about doing this? All of the courses I've taken are basic understanding of Apex and how to write small triggers, classes and queries. The agency who built the class left 0 documentation on its code.
You can't write code in production so whatever you'll try to do - will have to be done in sandbox, tested and then deployed.
There's a way to do a "destructive deployment" and really delete it but you'll need programming tools (VSCode, Eclipse IDE or Ant + Migration Tool). It's bit advanced topic, I'd suggest you hire a dev ;) or try to just comment them out.
In sandbox you can comment out the body (bodies?) of triggers and classes. You shouldn't kill whole file, leave some empty skeletons like
public with sharing class MqlGenerator{
/* kill everything
*/
}
trigger MqlTrigger on MQL__c (after insert){
/* kill everything
*/
}
Of course if there's trigger on Account and it does 10 things, only 2 of them relate to MQL then don't comment everything out ;) It'll be bit of trial and error for you, depends how clean the code is.
You will have to touch triggers, normal classes and likely unit tests too because if they did decent job - there will be tests that verify these triggers do something and now these tests will start to fail.
Add the files to changeset as you go (you do changesets, right? Doesn't sound like you deploy with Git+SFDX for example). From time to time run Apex Classes -> Compile all classes and run unit tests. Some manual testing wouldn't hurt too. If you are unsure what's left you can click on MQL's fields, there's "Where is this used?" button. Or even try clicking delete & repeating until it succeeds ;)
After you deploy this changeset...
If the MQL__c has no triggers (for example it is created in Account updates but itself doesn't have triggers), you might actually be able to delete the object. If there are related triggers, workflows etc SF will stop you. The only way to really delete it would be to run this destructive deploy. It's possible without installing anything, use the link I included and for example workbench would let you make a deployment. But it's bit "pro", if you're unsure start with commenting stuff out and maybe leave the empty skeleton until you're more comfortable. You can always hide the object's Tab, remove right to Read the object and it'll disappear from listviews, reports... it'll be an eyesore only for sysadmins.
If object has to stay around but the data storage is significant you could try truncating the object. If it gives you trouble - Data Loader, export all records (just IDs), then delete. Maybe even with hard delete option so you skip recycle bin.
I tried deploying the sandbox into Salesforce production but getting some errors. Also is it possible to make changes to the production code without the sandbox? Can someone also explain the code coverage? I tried changing that error field for the insert several times in the sandbox, But when I try to deploy it again, it still throws the same errors. enter image description here
The error clearly states that your test class is trying to insert an opportunity record without filling mandatory field Close Date. Please check your code again. If you need any help please share the snippet of the code.
And yes you can make changes to Production directly, I wouldn't recommend that. Moving changes from sandbox to production after necessary testing is an ideal way of deploying new/existing changes. It's part of SDLC practice.
The yeoman generators "meanjs" automagically installs a core and a user module when you do a fresh generation. My goal is to remove the user module and only use the core.
Any ideas? I considered sharing code but I'm not sure it would help.
Thanks
More Info:
The reason i'd like to remove this is because the web application I'm creating requires ZERO user management
The easiest option would simply be:
First make sure that you are able to run your code.
Delete the users folder.
Run your code, which will fail probably, and look at the errors.
Go through all the error messages and delete every link to the users module.
Note: this is applicable for MEAN version 0.4.X and above.
I've been following this tutorial http://www.magentocommerce.com/knowledge-base/entry/tutorial-creating-a-magento-widget-part-1 to create a Magento widget as part of an extension I'm working on.
Whilst the widget was created successfully and worked as I wanted it, I changed the code and started getting the following error
Warning: Invalid argument supplied for foreach() in app/code/core/Mage/Widget/Model/Widget/Instance.php on line 502
When I changed the code back, the error was still present. However when I copied all my module to a fresh Magento install then the error wouldn't appear.
Although my widget does not explicitly use the database does anyone know if the act of installing and uninstalling a Magento widget makes changes to the core databases tables and if it does, which tables are altered.
Thanks
The core_resource table contains a list of all modules, so adding a new module will cause a new row to be created.
If you have anything in your module's sql folder, that code will be run depending on your module's version.
Without knowing exactly what code was run and changed, it's hard to know what your specific problem is.
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources
So if you followed that tutorial you linked to I do not think it changed any database settings.
You can tell if a module will add tables or modify table columns by the following method.
Assume the module is called Foo_Bar and it is installed in the "community" code pool (as opposed to core or local).
Navigate to app/code/community/Foo/Bar. You will at minimum usually see etc and Block directories there.
If you see a sql directory then this module makes db changes. You also need to understand a module is versioned and may initially make a certain table and then modify it.
By way of example you can go to any core module and look for the same. For example I am running Enterprise 1.12 and went to:
app/code/core/Mage/Sendfriend/sql/sendfriend_setup
I see:
mysql4-upgrade-1.5.9.9-1.6.0.0.php
mysql4-upgrade-0.7.3-0.7.4.php
mysql4-upgrade-0.7.2-0.7.3.php
mysql4-upgrade-0.7.1-0.7.2.php
mysql4-install-0.7.0.php
install-1.6.0.0.php
Note the upgrade x-y nomenclature. That is what core_resource keeps track of.
If you are wondering where your new module's settings are saved, that is actually in core_config_data. try this:
SELECT * FROM core_config_data where path like '%foo%';
Assuming you have some setting in the admin you named "foo".
Now back to your problem. That is a common php error. You are running a foreach on something which can not be iterated. The code right before that is probably not returning an array or collection or whatever.
Ideally you should always wrap the foreach with a statement that checks that the item you are iterating over is not empty.
You can also turn off displaying errors or suppress that error using the # statement which is a bad practice...