Is there a typesafe way to work with rowCause?
On the project I'm currently working with, we have Apex Sharing Rules.
I see we are passing rowCause as a String everywhere.
But the values of these Strings look like API names.
Is there a typesafe way we can work with these?
apex api apex-managed-sharing sharing-rule type
asked Nov 25 at 4:09
Brian Kessler
1,5401131
add a comment |
On the project I'm currently working with, we have Apex Sharing Rules.
I see we are passing rowCause as a String everywhere.
But the values of these Strings look like API names.
Is there a typesafe way we can work with these?
apex api apex-managed-sharing sharing-rule type
asked Nov 25 at 4:09
Brian Kessler
1,5401131
add a comment |
On the project I'm currently working with, we have Apex Sharing Rules.
I see we are passing rowCause as a String everywhere.
But the values of these Strings look like API names.
Is there a typesafe way we can work with these?
apex api apex-managed-sharing sharing-rule type
asked Nov 25 at 4:09
Brian Kessler
1,5401131
On the project I'm currently working with, we have Apex Sharing Rules.
I see we are passing rowCause as a String everywhere.
But the values of these Strings look like API names.
Is there a typesafe way we can work with these?
apex api apex-managed-sharing sharing-rule type
apex api apex-managed-sharing sharing-rule type
asked Nov 25 at 4:09
Brian Kessler
1,5401131
asked Nov 25 at 4:09
Brian Kessler
1,5401131
asked Nov 25 at 4:09
Brian Kessler
1,5401131
asked Nov 25 at 4:09
Brian Kessler
1,5401131
asked Nov 25 at 4:09
Brian Kessler
1,5401131
1,5401131
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Refer this documentation: Sharing a Record Using Apex
Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name:
- The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench.
- The name is used when referencing the reason in the API and Apex.
All Apex sharing reason names have the following format:
MyReasonName__c
Apex sharing reasons can be referenced programmatically as follows:
Schema.CustomObject__Share.rowCause.SharingReason__c
For example, an Apex sharing reason called Recruiter for an object called Job can be referenced as follows:
Schema.Job__Share.rowCause.Recruiter__c
So, sharing reason must be used which you have defined and that's why it takes API name. It always hold String value.
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
add a comment |
Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console:
System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String);
I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some special type.
However if you want to validate that it's a proper RowCause, you can do:
List<Schema.PicklistEntry> rowCauses = MyObj__Share.rowCause.getDescribe().getPicklistValues();
The results you get back will include all the custom row causes and the standard allowable ones too.
answered Nov 25 at 16:39
Charles T
6,1961721
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "459"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f240417%2fis-there-a-typesafe-way-to-work-with-rowcause%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Refer this documentation: Sharing a Record Using Apex
Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name:
- The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench.
- The name is used when referencing the reason in the API and Apex.
All Apex sharing reason names have the following format:
MyReasonName__c
Apex sharing reasons can be referenced programmatically as follows:
Schema.CustomObject__Share.rowCause.SharingReason__c
For example, an Apex sharing reason called Recruiter for an object called Job can be referenced as follows:
Schema.Job__Share.rowCause.Recruiter__c
So, sharing reason must be used which you have defined and that's why it takes API name. It always hold String value.
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
add a comment |
Refer this documentation: Sharing a Record Using Apex
Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name:
- The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench.
- The name is used when referencing the reason in the API and Apex.
All Apex sharing reason names have the following format:
MyReasonName__c
Apex sharing reasons can be referenced programmatically as follows:
Schema.CustomObject__Share.rowCause.SharingReason__c
For example, an Apex sharing reason called Recruiter for an object called Job can be referenced as follows:
Schema.Job__Share.rowCause.Recruiter__c
So, sharing reason must be used which you have defined and that's why it takes API name. It always hold String value.
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
add a comment |
Refer this documentation: Sharing a Record Using Apex
Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name:
- The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench.
- The name is used when referencing the reason in the API and Apex.
All Apex sharing reason names have the following format:
MyReasonName__c
Apex sharing reasons can be referenced programmatically as follows:
Schema.CustomObject__Share.rowCause.SharingReason__c
For example, an Apex sharing reason called Recruiter for an object called Job can be referenced as follows:
Schema.Job__Share.rowCause.Recruiter__c
So, sharing reason must be used which you have defined and that's why it takes API name. It always hold String value.
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
Refer this documentation: Sharing a Record Using Apex
Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name:
- The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label is also enabled for translation through the Translation Workbench.
- The name is used when referencing the reason in the API and Apex.
All Apex sharing reason names have the following format:
MyReasonName__c
Apex sharing reasons can be referenced programmatically as follows:
Schema.CustomObject__Share.rowCause.SharingReason__c
For example, an Apex sharing reason called Recruiter for an object called Job can be referenced as follows:
Schema.Job__Share.rowCause.Recruiter__c
So, sharing reason must be used which you have defined and that's why it takes API name. It always hold String value.
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
answered Nov 25 at 4:34
Santanu Boral
30.4k52152
30.4k52152
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
add a comment |
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
Thanks for the link, but I think you missed the point of the question... I want to know if there is a typesafe way to work with rowCause. For example, if I pass the value of rowCause from one method to another, could I create a method private void doSomething(RowCause rowCause) { /* do whatever */} which won't accept strings which are not valid rowcauses, and to which I can only pass a valid rowCause by using its API name.
– Brian Kessler
Nov 25 at 10:25
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
@BrianKessler But the direct answer to that question is a simple "No", which doesn't add a lot of value for anyone. Both Santanu's and Charles' answers seem to me to illuminate different aspects of how you can get some level of compile- and run-time validation of the use of row cause values.
– David Reed
Nov 25 at 16:41
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
I appreciate the additional information, but I also appreciate directness. Of course nothing says the two need be mutually exclusive. :-) Anyway, I'll leave this question just in case some-else knows a way to make that a "Yes".
– Brian Kessler
Nov 26 at 9:04
add a comment |
Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console:
System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String);
I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some special type.
However if you want to validate that it's a proper RowCause, you can do:
List<Schema.PicklistEntry> rowCauses = MyObj__Share.rowCause.getDescribe().getPicklistValues();
The results you get back will include all the custom row causes and the standard allowable ones too.
answered Nov 25 at 16:39
Charles T
6,1961721
add a comment |
Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console:
System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String);
I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some special type.
However if you want to validate that it's a proper RowCause, you can do:
List<Schema.PicklistEntry> rowCauses = MyObj__Share.rowCause.getDescribe().getPicklistValues();
The results you get back will include all the custom row causes and the standard allowable ones too.
answered Nov 25 at 16:39
Charles T
6,1961721
add a comment |
Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console:
System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String);
I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some special type.
However if you want to validate that it's a proper RowCause, you can do:
List<Schema.PicklistEntry> rowCauses = MyObj__Share.rowCause.getDescribe().getPicklistValues();
The results you get back will include all the custom row causes and the standard allowable ones too.
answered Nov 25 at 16:39
Charles T
6,1961721
Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console:
System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String);
I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some special type.
However if you want to validate that it's a proper RowCause, you can do:
List<Schema.PicklistEntry> rowCauses = MyObj__Share.rowCause.getDescribe().getPicklistValues();
The results you get back will include all the custom row causes and the standard allowable ones too.
answered Nov 25 at 16:39
Charles T
6,1961721
answered Nov 25 at 16:39
Charles T
6,1961721
answered Nov 25 at 16:39
Charles T
6,1961721
answered Nov 25 at 16:39
Charles T
6,1961721
6,1961721
add a comment |
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f240417%2fis-there-a-typesafe-way-to-work-with-rowcause%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
