• David Wery
  • NEWBIE
  • 0 Points
  • Member since 2018
  • CEO
  • Yelido


  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 1
    Likes Given
  • 2
    Questions
  • 2
    Replies
Hi all,

We need to package and deploy in a DX environment the following code :
CaseShare userShare = new CaseShare();
userShare.CaseId = <case_id>;
userShare.UserOrGroupId = <user_id>;
userShare.CaseAccessLevel = 'Edit';
insert userShare;

The execution of the deployment process fails :
sfdx force:source:push -u <scratchorglabel>

Field is not writeable: CaseShare.CaseId (66:23)
Field is not writeable: CaseShare.UserOrGroupId (67:23)
Field is not writeable: CaseShare.CaseAccessLevel (69:27)
Field is not writeable: CaseShare.CaseAccessLevel (71:27)
DML operation Insert not allowed on CaseShare (73:13)

Apparently, this occurs when the sharing settings (here the Case object) is set to 'Public". The case object meta-data has sharing settings set to private but, based on what I see, it looks to be ignored during the push (see case.object-meta.xml below)
<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
    <actionOverrides>
        <actionName>Accept</actionName>
        <type>Default</type>
    </actionOverrides>
    
   ...
    <sharingModel>Private</sharingModel>
</CustomObject>
Can someone help me on getting the insert of the sharing rule correctly packaged (unmanaged)?

Thanks!
 
We are currently implementing a product catalog in our Sales and Services process. Our need is to be able to define a technical Product that will be used on several commercial offers, with different prices (alone or part of a bundle).

I've seen in the model that a PricebookEntry have 2 lookup fiels on Product and PriceBook. So, we could theoritically have the same product applied to the same Pricebook multiple times, that would fit our needs (on PricebookEntry per commercial offer with specific prices and which links to the Product entity).

Unfortunatly, I see that this is not possible to have the same product, multiple time in the same Pricebook (for example, see https://developer.salesforce.com/forums/?id=906F00000008pdIIAQ).

Before creating new custom objects to fix our needs, I would like to know what is the State of the Art way of managing such needs inside SFDC.

Thanks!
Hi,

Just in case this helps somebody! It tooks quite a bit of time to track this issue down.

We've had an issue with the sfdx force:data:tree:import command failing with a MALFORMED_ID message when trying to resolve references during data imports.   It turns out the issue was realated to our namespace, which has numbers in it, which the sfdx tool didn't handle.  
 
An example is :-

plan.json
 
[
    {
        "sobject": "i42as__testParent",
        "saveRefs": true,
        "files": [
            "parent.json"
        ]
    },
    {
        "sobject": "i42as__testChild",
        "resolveRefs": true,
        "files": [
            "child.json"
        ]
    }
]

parent.json 
 
{
    "records": [
        {
            "attributes": {
                "type": "i42as__testParent__c",
                "referenceId": "parentRef1"
            },
            "i42as__Message": "Hello"
        }
    ]
}

child.json
{
    "records": [{
        "attributes": {
            "type": "i42as__testChild__c",
            "referenceId": "testChildRef1"
        },
        "i42as__parent__c": "@parentRef1"
    }]
}

When run with the following command, this returns an error.  
 
sfdx  force:data:tree:import --plan plan.json

STATUSCODE    MESSAGE                                                                    FIELDS
────────────  ─────────────────────────────────────────────────────────────────────────  ───────────────────────────
MALFORMED_ID  Object: id value of incorrect type: @parentRef1  i42as__parent__c
=== testChildRef1 [1]

In turns out this was an error in the salesforce-alm library, the regex used to look for the @parentRef1 replacement was not expecting a number in the namespace.  I've managed to work around the issue by changing the file .local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/data/dataImportApi.js as follows;-
 
const jsonRefRegex = /[.]*["|'][A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;
const jsonRefRegex = /[.]*["|'][0-9A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;



 

I am taking reference from here to create an attachment , Can i use the same from trigger instead of button.I am getting

System.VisualforceException: Getting content from within triggers is currently not supported. Exception.

Please Help.

Hi,

Just in case this helps somebody! It tooks quite a bit of time to track this issue down.

We've had an issue with the sfdx force:data:tree:import command failing with a MALFORMED_ID message when trying to resolve references during data imports.   It turns out the issue was realated to our namespace, which has numbers in it, which the sfdx tool didn't handle.  
 
An example is :-

plan.json
 
[
    {
        "sobject": "i42as__testParent",
        "saveRefs": true,
        "files": [
            "parent.json"
        ]
    },
    {
        "sobject": "i42as__testChild",
        "resolveRefs": true,
        "files": [
            "child.json"
        ]
    }
]

parent.json 
 
{
    "records": [
        {
            "attributes": {
                "type": "i42as__testParent__c",
                "referenceId": "parentRef1"
            },
            "i42as__Message": "Hello"
        }
    ]
}

child.json
{
    "records": [{
        "attributes": {
            "type": "i42as__testChild__c",
            "referenceId": "testChildRef1"
        },
        "i42as__parent__c": "@parentRef1"
    }]
}

When run with the following command, this returns an error.  
 
sfdx  force:data:tree:import --plan plan.json

STATUSCODE    MESSAGE                                                                    FIELDS
────────────  ─────────────────────────────────────────────────────────────────────────  ───────────────────────────
MALFORMED_ID  Object: id value of incorrect type: @parentRef1  i42as__parent__c
=== testChildRef1 [1]

In turns out this was an error in the salesforce-alm library, the regex used to look for the @parentRef1 replacement was not expecting a number in the namespace.  I've managed to work around the issue by changing the file .local/share/sfdx/client/node_modules/salesforce-alm/dist/lib/data/dataImportApi.js as follows;-
 
const jsonRefRegex = /[.]*["|'][A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;
const jsonRefRegex = /[.]*["|'][0-9A-Z_]*["|'][ ]*:[ ]*["|']@([A-Z0-9_]*)["|'][.]*/igm;