Is there a typesafe way to work with rowCause?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}






up vote
1
down vote

favorite












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?










share|improve this question




























    up vote
    1
    down vote

    favorite












    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?










    share|improve this question
























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      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?










      share|improve this question













      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked yesterday









      Brian Kessler

      1,4711131




      1,4711131






















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          4
          down vote













          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.







          share|improve this answer





















          • 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
            17 hours ago










          • @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
            11 hours ago


















          up vote
          1
          down vote













          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.






          share|improve this answer





















            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',
            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
            });


            }
            });














             

            draft saved


            draft discarded


















            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








            up vote
            4
            down vote













            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.







            share|improve this answer





















            • 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
              17 hours ago










            • @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
              11 hours ago















            up vote
            4
            down vote













            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.







            share|improve this answer





















            • 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
              17 hours ago










            • @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
              11 hours ago













            up vote
            4
            down vote










            up vote
            4
            down vote









            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.







            share|improve this answer












            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.








            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 23 hours ago









            Santanu Boral

            29.6k52151




            29.6k52151












            • 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
              17 hours ago










            • @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
              11 hours ago


















            • 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
              17 hours ago










            • @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
              11 hours ago
















            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
            17 hours ago




            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
            17 hours ago












            @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
            11 hours ago




            @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
            11 hours ago












            up vote
            1
            down vote













            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.






            share|improve this answer

























              up vote
              1
              down vote













              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.






              share|improve this answer























                up vote
                1
                down vote










                up vote
                1
                down vote









                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.






                share|improve this answer












                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 11 hours ago









                Charles T

                6,0121719




                6,0121719






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    Accessing regular linux commands in Huawei's Dopra Linux

                    Can't connect RFCOMM socket: Host is down

                    Kernel panic - not syncing: Fatal Exception in Interrupt