1 2 Previous Next 16 Replies Latest reply: Jun 19, 2013 3:36 AM by 886436 RSS

    xComments field not be inherited

    886436
      Hello! When updating the document/creating new revisions, is there a way to make the comments field NOT inheriting from the previous revisions, but also be reset to blank? Which service/idoc defines or presents the comments on the UCM UI when content is being updating/checked in?

      Thank you for your help!
        • 1. Re: xComments field not be inherited
          Jiri.Machotka-Oracle
          You could do that simply with profiles/rules (e.g. blank the xComments field on check-ins).
          • 2. Re: xComments field not be inherited
            886436
            That's true - I didn't think of this!

            Where would you set this value in the Rule? Also, do you remember the idoc variable to clear it?

            Thanks!
            • 3. Re: xComments field not be inherited
              Jiri.Machotka-Oracle
              I thought it would be simpler, but I found a way - or, two ways, in fact.

              Originally, I thought it would be possible to use default or derived values defined in a rule (see http://docs.oracle.com/cd/E23943_01/doc.1111/e10978/c04_metadata.htm#DAFHGHID ) to clear the value of the xComments fields. Unfortunately,
              - default values do not override a value, if already exists
              - derived values can only be used on submit or import events

              #1. you could still go with 'Use Custom Include', where you can define whatever necessary in an idocScript include (that is merged into the DpDisplayIncludes table), but since this include does not exist yet, you'd need to create it in a custom component

              #2. if you want to avoid that, you will need an extra metadata field, which will be used for editing of comments for new versions. I will describe the details below, but I'm not sure if I like this way.

              a) so, let's assume that you define a new Memo field called myComments

              b) you want to use this field whenever a new version appears, so you will create a Rule 1, that will show this field (Edit), but hide the standard xComments

              c) on the other hand, when a user watches the content (DOC_INFO, or UPDATE) you want to display xComments, so you will create another Rule 2. Both the rules will be added to your profile.

              d) finally, you create a global Rule 3 that will copy the value from myComments to xComments and erase the value from myComments. Here, you will already need a bit of idocScript (but this one can be written directly to the rule)

              For xComments you will use derived value with
              <$dprDerivedValue=#active.xmyComments$>
              whilst for myComments it'll be just
              <$dprDerivedValue=""$>
              e) another very important piece is rule activation conditions for each rule (defining when a rule is applied)

              Rule 1: (dpEvent like "OnRequest") and ((dpAction like "CheckinNew") or (dpAction like "CheckinSel"))
              Rule 2: (dpAction like "Update") or (dpAction like "Info")
              Rule 3: (dpEvent like "OnSubmit") and ((dpAction like "CheckinNew") or (dpAction like "CheckinSel"))
              • 4. Re: xComments field not be inherited
                886436
                Hello

                How to setup a rule (in this case I am setting up a SideEffect), that when a certain metadata field changes (xEumRev in our case), upon the checkin of the document the comments field is cleared out? I am a bit lost on how to define this in iDoc?
                Thank you for your help!
                • 5. Re: xComments field not be inherited
                  886436
                  jiri.machotka, thank you for your suggestions, I will try that as well! Actually, simply setting <$xComments=''$> in the Side Effects tab if the "dpAction like "CheckinSel" or dpAction like "CheckinNew" " - makes it work!!!

                  Yet, I had found another requirement on this, which changes the scenario slightly and which I had just realized: I need to clear the comments field ONLY if a certain metadata changes (we are using a different metadata for user-defined revisions, so if the user changes the xEumRev field, the Comments need to be cleared upon the checkin).

                  How would that be setup in the Side Effects? Basically I need to add a loop to check if my xEumRev field has changed during the Checkin. And if yes, set xComments=''.
                  Any ideas how would I check if the xEumRev field has changed value?
                  • 6. Re: xComments field not be inherited
                    886436
                    jiri.machotka, thank you for your suggestions, I will try that as well! Actually, simply setting <$xComments=''$> in the Side Effects tab if the "dpAction like "CheckinSel" or dpAction like "CheckinNew" " - makes it work!!!

                    Yet, I had found another requirement on this, which changes the scenario slightly and which I had just realized: I need to clear the comments field ONLY if a certain metadata changes (we are using a different metadata for user-defined revisions, so if the user changes the xEumRev field, the Comments need to be cleared upon the checkin).

                    How would that be setup in the Side Effects? Basically I need to add a loop to check if my xEumRev field has changed during the Checkin. And if yes, set xComments=''.
                    Any ideas how would I check if the xEumRev field has changed value?
                    • 7. Re: xComments field not be inherited
                      Jiri.Machotka-Oracle
                      when a certain metadata field changes (xEumRev in our case), upon the checkin of the document the comments field is cleared out?
                      You can't do that with rules. Rules are declarative, and are executed on the server-side.

                      You will only get OnRequest event when the profile is requested, and OnSubmit when it is submitted. What's in between cannot be monitored by rules.

                      Client-side events can be processed by a Javascript customization in the standard template, or in a custom include.
                      • 8. Re: xComments field not be inherited
                        886436
                        What if I check this during the OnSubmit event? Let's say I've checked the value of xEumRev before this event and then after the OnSubmit. If the value has changed after OnSubmit - I can clear the comments. Is that possible to do via rules then?
                        • 9. Re: xComments field not be inherited
                          886436
                          What if I check this during the OnSubmit event? Let's say I've checked the value of xEumRev before this event and then after the OnSubmit. If the value has changed after OnSubmit - I can clear the comments. Is that possible to do via rules then?
                          • 10. Re: xComments field not be inherited
                            886436
                            What if I check this during the OnSubmit event? Let's say I've checked the value of xEumRev before this event and then after the OnSubmit. If the value has changed after OnSubmit - I can clear the comments. Is that possible to do via rules then?
                            • 11. Re: xComments field not be inherited
                              Jiri.Machotka-Oracle
                              Yop, you can. It's what 'Derived Values' are about (you have the idocScript coding in my previous post as well as hints for Rule Activation Condition).

                              I'm not sure, however, if you will have the user experience you expect - OnSubmit is triggered only after you click the 'Check In' button is clicked. So, a user will watch something, maybe even edit it, and you will change it, then - that's why the trick with two fields is necessary.
                              • 12. Re: xComments field not be inherited
                                886436
                                I've tried to implement your scenarios - that actually works great, however, I need to slighlty modify the logic according to my requirement I've mentioned during the last reply.
                                I now have my two extra fields (dRevLabel and myEumRevLabel). myEumRevLabel is in it's own Rule and derives value from dRevLabel field). Am I thinking this through correctly: I need to check the two values of myEumRevLabel BEFORE the update and AFTER the update. If the two values had changed - I will set the xComments field to blank. I am lost on how to check this difference in UCM via rules. Do I need to use the "On Request" event to check the value BEFORE the update? Is it possible to do this at all?

                                Thanks!
                                • 13. Re: xComments field not be inherited
                                  Jiri.Machotka-Oracle
                                  First of all, dRevLabel is hardly an extra field. It is a string value, which contains a "Revision label. Can be a duplicate and have its own incrementing algorithm. This is the external revision identifier."

                                  If I got what you do, you copy the content of dRevLabel to you custom field myEumRevLabel in its own (OnSubmit - based on "derives value from dRevLabel field"), and now, you want to check whether myEumRevLabel still equals dRevLabel, and if so, set xComments to blank. Did I get it right?

                                  - First of all, if your myEumRevLabel is also a string, the difference comparison is really easy.
                                  <$if not strEquals(#active.dRevLabel, #active.xmyEumRevLabel)$> ... <$endif$>
                                  - However, you don't need to do that - if you are processing CheckinNew, or CheckinSel dpAction for OnSubmit dpEvent, you already know (from the rule activation condition itself) that there is a new revision
                                  - Besides, it does not resolve the issue that on the check-in form a user will still see (for a new revision!) comments from the previous one, which you can then delete when the content is submitted

                                  Let me repeat: you can catch pre-processing (or BEFORE the update), but derived values don't work there, and default values work only if the value is blank.

                                  If you follow the scenario literally as I described it, it will work. But if I were you, I'd probably go with Custom Includes, because creating an extra MEMO field just because of usability looks ugly.
                                  • 14. Re: xComments field not be inherited
                                    886436
                                    Do you mean custom includes in code (custom component)? Or also included in the Rules/Profiles?

                                    Thank you!
                                    1 2 Previous Next