Skip to main content
Themen#Org-Dependent Packages

#Org-Dependent Packages0 diskutieren mit

Eine Frage stellen...
Keir Bowden (Independent Salesforce Specialist bei Self-employed) postete in * Salesforce Developers *
8. Sept. 2023, 16:30

If you work for an end-user or SI partner and are interested in using modern package based development in a mature org, come along to my session in the Developer Theatre. I'll demonstrate how org-dependent packaging can play nicely with even the richest happy soup, without the need to deconstruct the soup into its basic ingredients. 

If you work for an end-user or SI partner and are interested in using modern package based development in a mature org, come along to my session in the Developer Theatre.

Event if you aren't attending Dreamforce, there's plenty of useful resources to get you started.

 

In the session I demonstrated an application built with a combination of a fairly simple Bookstore "Happy Soup" and an org-dependent package that added the concept of book readings by authors. You can find the source to each of these on Github (after the session completes - links are not public yet) :

Trailhead, as usual, is a great place to start learning:

And a few other links that should prove useful:

#Unlocked Packaging #Org-Dependent Packages #SFDX #Dreamforce2023

3 Kommentare
Kommentar schreiben...
0/9000
Sanket Nagpure (Senior Associate bei Ensono Technologies LLP) fragte in #AppExchange
1. Nov. 2021, 07:02
Any one having idea that how can we cover the rootstock community object trigger classes

I have a work order (rstk__wocst__c) which is a rootstock community object and as per the best practice I have covered the WorkOrderTriggerHander class  83%  

but it has not covered my trigger. which is shown "Your code coverage is 0%. You need at least 75% coverage to complete this deployment."

 

does anyone knows how to cover this rootstock object trigger.?  

 

Any one having idea that how can we cover the rootstock community object trigger classes

Thank you

2 Antworten
  1. Sanket Nagpure (Ensono Technologies LLP)
    3. Nov. 2021, 12:58

    Hi Kermit,

     

    Thanks for the reply!..

     

    Right now I have resolved this problem but next time I am having any suggestions regarding the coding issue I will post my question in the above-given link.

     

    Thank you for guidence

Antwort schreiben...
0/9000
Marc Behr (Salesforce Technical Director bei Copeland) postete in Salesforce DX
30. Aug. 2021, 15:58

I have several org-dependent packages that up until today, I have been able to install in sandboxes without any issues. Over the weekend, the Winter'22 release was installed in my sandboxes and now when I try to install the packages, I get errors on record types:

 

duplicate value found: <unknown> duplicates on record with id: <unknown>

 

Obviously one of the less than helpful messages. :-( 

 

When I created a new sandbox from production (so it stays on the Summer'21 release), the package installs without error.

#Winter '22 #SFDX CLI #Org-Dependent Packages

20 Kommentare
Kommentar schreiben...
0/9000
Sarah Kennedy (Senior Salesforce Developer bei Steampunk) postete in Unlocked Packages
7. Juli 2021, 12:38

Hi - We are looking to add a Role to a 2GEN Unlocked package. To add this Role, we also need to add its hierarchy as each role references a parent up to the top 'Admin' role which does not.

 

When creating a new package version we are getting errors such as:

field integrity exception: unknown (Case access level below organization default) field integrity exception: unknown (Opportunity access level below organization default)  

The roles have either view or edit access: 

Opportunity Access | Users in this role can view all opportunities associated with accounts that they own, regardless of who owns the opportunities Case Access | Users in this role can view all cases associated with accounts that they own, regardless of who owns the cases

 

I  tried using unpackagedMetadata in the sfdx-project.json file and added Account, Case, Opportunity objects. We don't want those objects within the package. But am still getting those same errors.

 

Is this the right approach? How can I overcome the errors?

 

Thanks.

5 Kommentare
  1. Adrian Shiel (VISEO Group)
    11. Juli 2021, 22:22

    What does your role metadata look like for the package?  Have you experimented with not putting Case Access and Opp Access in the metadata?

     

    I haven't looked at our role meta for a while and I know we have the different Access Levels present but our Role metadata also has CaseAccessLevel but set to none.  We have NO case object in any of our Unlocked Packages and it packages just fine.  If you read the metadata type, the only Required field stated is Name (parent role optional and if needed.)

Kommentar schreiben...
0/9000
Marc Behr (Salesforce Technical Director bei Copeland) postete in Unlocked Packages
6. Juli 2021, 12:40

Hi @Dileep Burki What are the chances of Org Dependent packages not making it out of beta (I know, Safe Harbor applies)? In the event that it did not move to GA and were to be depreciated, what would happen to any existing packages? #Org-Dependent Packages

5 Kommentare
  1. Penelope Cameron
    8. Juli 2021, 17:49

    Totally fine! It's hard to keep up on every release note and announcement. Typically if the doc on the feature doesn't list (Beta) or (Pilot) in the title and have a beta/pilot disclaimer, then the feature is GA.  So if in doubt on whether a feature is GA, check the doc https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm  But occasionally I get behind on doc updates, so that's 98% accurate.

Kommentar schreiben...
0/9000
Azlam Abdulsalam (Head of Engineering bei Flxbl) postete in Unlocked Packages
21. Feb. 2021, 09:02

@Dileep Burki  Org dependent packages do not support inclusion of standard value sets, throws.an exception while creating it. However, unlocked packages do not have any issues, it allows for creation with the downside being it wont be reflected in the target org. This makes sense from a perspective of a unlocked package (as I dont want a third party unlocked package to overwrite my org settings), However it should not be the case for org dependent one's. They are private to my org and should be allowed. Atleast it should not error out.. this makes the adoption very hard. Any alternate thoughts?

2 Kommentare
Kommentar schreiben...
0/9000