Clarity

  • 1.  What is behind resolved risk?

    Posted Nov 07, 2016 09:38 AM

    Reading

    https://communities.ca.com/message/241866574?commentID=241866574#comment-241866574 

    and Dale_Stockman 

    posts in it which says among other things

    but, in CA PPM, when the status is changed from resolved to closed, the "Date Resolved" field gets cleared by a hidden process or bit of code

     

    1. Is the display of read only fields Resolved By and Resolution Date done by a hidden process or a bit of code only or is that accessible?

     

    2. Can that same functionality be brought to Change Request which do not have Resolved By and Resolution Date fields but does have the same Status lookup field with Resolved value?

     

    3. Further could the same functionality be created for the Closed status and custom Closed By and Closed Date fields?

     

    Just wondering again ...

    The fields

    Resolution Date    
    Resolved By
    Last Updated Date    
    Last Updated By
    Created Date    
    Created By

    are read only without a default. When I try to get a read only field there is the message

    ( In order to make an attribute read-only a default must be selected )

    How do I get a read only field with no default?

    Like if I have the Closed Date field and I do not want the users to fill it, but want to use a process to fill it, if a default is required eventually as time passes by it it going to be before the created date which is not reasonable.



  • 2.  Re: What is behind resolved risk?

    Posted Nov 07, 2016 12:28 PM

    Hi Martti.

       We do Closed By & Closed Date as appropriate. Here's an Idea to Allow NULL Read Only Attributes to best 'catch' the data. Until those exist, I have a little (unsupported) work-around at the bottom of the thread. I don't know where the code is on the OOTB stampings. We have processes in place to stamp the other data elements as appropriate.

     

    For example, here is Date Stamp Issue Closed Date GEL.

    <gel:script xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:core="jelly:core" xmlns:gel="jelly:com.niku.union.gel.GELTagLibrary"
      xmlns:jxml="jelly:xml" xmlns:soap="jelly:com.niku.union.gel.SOAPTagLibrary" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:sql="jelly:sql" xmlns:util="jelly:util" xmlns:xog="http://www.niku.com/xog" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <gel:parameter default="your_xog_username" var="xogUsername"/>
      <gel:parameter default="your_xog_password" secure="true" var="xogPassword"/>
      <!-- Get issue data & date -->
      <gel:setDataSource dbId="niku"/>
      <sql:query escapeText="false" var="data">
             SELECT I.NAME ISSUE_NAME
             , I.RIM_RISK_ISSUE_CODE ISSUE_CODE
             , P.CODE PROJECT_CODE
             , R.UNIQUE_NAME AS ISSUE_ASSIGNED_TO
             , CAST(GETDATE() AS DATE) AS DATE
             , A.OSUWMC_WIP_DATE
             FROM RIM_RISKS_AND_ISSUES I
             JOIN INV_INVESTMENTS P ON P.ID = I.PK_ID
             JOIN ODF_CA_ISSUE A ON A.ID = I.ID
             JOIN SRM_RESOURCES R ON R.USER_ID = I.ASSIGNED_TO
             WHERE I.TYPE_CODE = 'ISSUE'
             AND I.ID = ${gel_objectInstanceId}
       </sql:query>
      <!--  Get xog URL from application by fpena -->
      <core:invokeStatic className="com.niku.union.config.ConfigurationManager" method="getInstance" var="config"/>
      <core:set var="v_IsLocal">0</core:set>
      <core:set value="${config.getProperties().getWebServer().getWebServerInstance(0).getId()}" var="WebServerid"/>
      <core:if test="${WebServerid == 'app'}">
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(0).getAddress()}" var="AddressIp"/>
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(0).getSslEntryUrl()}" var="EntryURL"/>
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(0).getSslPort()}" var="Port"/>
        <core:if test="${EntryURL == 'http://localhost' }">
          <gel:log level="info" message="NULL ADDRESS IS LOCAL... "/>
          <core:set var="v_IsLocal">1</core:set>
          <core:set var="AddressIp">${EntryURL}</core:set>
        </core:if>
      </core:if>
      <core:if test="${WebServerid == 'nsa'}">
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(1).getAddress()}" var="AddressIp"/>
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(1).getEntryUrl()}" var="EntryURL"/>
        <core:set value="${config.getProperties().getWebServer().getWebServerInstance(1).getPort()}" var="Port"/>
        <core:if test="${EntryURL == 'http://localhost' }">
          <gel:log level="info" message="NULL ADDRESS IS LOCAL... "/>
          <core:set var="v_IsLocal">1</core:set>
          <core:set var="AddressIp">${EntryURL}</core:set>
        </core:if>
      </core:if>
      <core:if test="${Port != null }">
        <core:set value="${EntryURL}" var="EntryURL"/>
      </core:if>
      <core:if test="${v_IsLocal == 0 }">
        <core:if test="${AddressIp != '' }">
          <core:set value="http://${AddressIp}" var="EntryURL"/>
        </core:if>
      </core:if>
      <core:set value="${config.getProperties().getDirectories().getInstallDir()}" var="NIKUHOME"/>
      <core:set value="${EntryURL}/niku/xog" var="xogURL"/>
      <!-- Log into xog and get a session ID -->
      <soap:invoke endpoint="${xogURL}" var="auth">
        <soap:message>
          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xog="http://www.niku.com/xog">
            <soapenv:Header/>
            <soapenv:Body>
              <xog:Login>
                <xog:Username>${xogUsername}</xog:Username>
                <xog:Password>${xogPassword}</xog:Password>
              </xog:Login>
            </soapenv:Body>
          </soapenv:Envelope>
        </soap:message>
      </soap:invoke>
      <!-- Checking whether a sessionID is returned. If not, it means that login was unsuccessful -->
      <gel:set asString="true" select="$auth/SOAP-ENV:Envelope/SOAP-ENV:Body/xog:SessionID/text()" var="sessionID"/>
      <core:choose>
        <core:when test="${sessionID == null}">
          <gel:log>Couldn't log in. Please check the hostname/username/password.</gel:log>
        </core:when>
        <core:otherwise>
          <gel:log>Login successful. Session ID is ${sessionID}</gel:log>
        </core:otherwise>
      </core:choose>
      <!-- Xog current date onto WIP Date  -->
      <soap:invoke endpoint="${xogURL}" var="runresult">
        <soap:message>
          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xog="http://www.niku.com/xog">
            <soapenv:Header>
              <xog:Auth>
                <xog:SessionID>${sessionID}</xog:SessionID>
              </xog:Auth>
            </soapenv:Header>
            <soapenv:Body>
              <NikuDataBus xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../xsd/nikuxog_issue.xsd">
                <Header action="write" externalSource="NIKU" objectType="issue" version="13.2.0.472"/>
                <issues>
                  <issue code="${data.rows.0.issue_code}" name="${data.rows.0.issue_name}" ownerCode="${data.rows.0.issue_assigned_to}" projectCode="${data.rows.0.project_code}">
                    <CustomInformation>
                      <ColumnValue name="osuwmc_close_date">${data.rows.0.date}</ColumnValue>
                    </CustomInformation>
                  </issue>
                </issues>
              </NikuDataBus>
            </soapenv:Body>
          </soapenv:Envelope>
        </soap:message>
      </soap:invoke>
      <!-- Log out of xog -->
      <soap:invoke endpoint="${xogURL}" var="logoutresult">
        <soap:message>
          <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xog="http://www.niku.com/xog">
            <soapenv:Header>
              <xog:Auth>
                <xog:SessionID>${sessionID}</xog:SessionID>
              </xog:Auth>
            </soapenv:Header>
            <soapenv:Body>
              <xog:Logout/>
            </soapenv:Body>
          </soapenv:Envelope>
        </soap:message>
      </soap:invoke>
      <!-- comment out below log output once in production  -->
      <gel:log> ${xogURL}, ${xogUsername}, ${xogPassword}, ${sessionID}, ${gel_objectInstanceId}, ${data.rows.0.inv_name}, ${data.rows.0.inv_code}, ${data.rows.0.osuwmc_init_date}, ${data.rows.0.osuwmc_init_days}</gel:log>
    </gel:script>

     

    A small downside to this is the OOTB notifications are still active and I have no way (that I know of) to affect this. Please vote up Migrate OOTB Issue, Risk and Change Request 'On Create' Workflows to the Process Engine Framework so we can all easily see, and modify, the OOTB processes.



  • 3.  Re: What is behind resolved risk?

    Posted Nov 07, 2016 03:35 PM

    Thank you Rob.

    So your answer to 2. and 3. question is Yes with a custom process.

    Answer + is the script you posted.

    For me who is struggling with elementary XOGing in gel that might even be a supported way of doing also something quite else which I could not make out of other samples.

    Thank kindly once more.



  • 4.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 01:37 AM

    Regarding the read only without a default is it feasible to lock the attribute on create and then unlock if needed based on status?



  • 5.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 04:20 AM

    ^ can do that with a couple of simple processes.

     

    Not sure what "feasible" means in this context though ; would load the process engine with some work to do, whether than is something that is to worry about would depend on volumes/frequency etc.



  • 6.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 04:36 AM

    Thanks Dave_3.0 

    It means is it doable, what are the consequences etc.

    Your answer sounds as if it is doable ie. the functionality appears to be the same or you get the same behaviour

    There is no more load on the system than with the Resolved functionality.



  • 7.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 04:59 AM

    Well there would be some load on the process engine (whereas the "resolved" stuff would be done in the code I would think) - but not much.



  • 8.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 07:39 AM

    For a non process based solution check out the code I have posted here: Allow NULL Read Only Attributes.

     

    1) Create Date attribute with no default value.

    2) Run the update command as appropriate to set read only.

    3) Restart the services.

     

    When things come back up you have NULL read only date attributes.



  • 9.  Re: What is behind resolved risk?

    Posted Nov 09, 2016 03:44 PM

    Thanks Robert_Ensinger ,  I saw that thread. Your solution has maybe no overhead or load, but not exactly supported, but maybe acceptable for custom attribute.