#Org-Dependent Packages0 debatiendo

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.?  

Thank you

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

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.

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

@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?