Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-2415

implement KR-WKFLW permission and responsibility checks

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-8759CONTRIB: Make sure (KR-WKFLW "Ad Hoc Review Document") set up for Adhoc routing for completion
      KULRICE-4327unable to find parameter: KR-WKFLW / CONFG / FROM_ADDRESS
      KULRICE-3984Cancel Document permission does not work
      KULRICE-4219Improvements to Permission and Responsibility maintenance
      KULRICE-7000Permission and Responsibility NamespaceCode+Name must be unique but the maintenance documents do not check this
      KULRICE-2414double check the permissions and responsibilities ailish created for rice modules
      KULRICE-8300problems with implementation of super user tab
      KULRICE-12705IT Failure DerivedComponentTest There should be some components for the KR-WKFLW namespace
      KULRICE-7074Restore Permission/Role/Responsibility logging
      KULRICE-2416all rice actions should extend KualiAction, so these permissions are enforced - they replace any existing app constants or configuration related to rice authz - please double check for any i missed
    • Rice Module:
      Rice Core, KSB, KNS, KEW, KEN, KCB, KIM, KOM
    • Application Requirement:
      KFS, KC, KS, Rice

      Description

      1. workflow should accept a KIM responsibility with template KR-WKFLW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type

      2. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
      format is template (attributes) - notes
      KR-WKFLW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
      KR-WKFLW Administer Routing for Document (Document Type) - this is super use permission
      KR-WKFLW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
      KR-WKFLW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
      KR-WKFLW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
      KR-WKFLW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
      KR-WKFLW Save Document (Document Routing Node & State) - this is an alternate for the policy

        Issue Links

          Activity

          Ailish Byrne made changes -
          Field Original Value New Value
          Summary CLONE -implementation of kim permissions and responsibilties in other rice modules implement KR-KEW permission and responsibility checks (eric)
          Description DONE

          1. provide support for reusable document values resolvers in workflow (eric)

          2. provide a mechanism for associating a document values resolver with a route node on the workflow document type (eric)

          3. create a route module that will route based on kim responsibilities (eric)

          4. develop the kim responsibility service with appropriate methods for use by the route module described in 3 (jonathan)

          5. create and assign permissions and responsibilities to account for standard functions in rice (ailish)
            format is template / permission namespace / permission details / roles granted...
              KR-KEW Ad Hoc Review Document / KR-SYS / RiceDocument / KR-SYS User
              KR-KEW Administer Workflow / KR-SYS / RiceDocument / KR-SYS Technical Administrator
              KR-KEW Blanket Approve Document / KR-SYS / RiceDocument / KR-SYS Technical Administrator, KFS-SYS Workflow Administrator
              KR-KEW Cancel Document / KR-SYS / RiceDocument / KR-KEW Initiator
              KR-KEW Initiate Document / KR-SYS / RiceDocument / KR-SYS User
              KR-KEW Prepare & Route Document / KR-SYS / RiceDocument / KR-KEW Initiator
              KR-KEW Save Document / KR-SYS / RiceDocument / KR-KEW Initiator
              KR-KNS Inquire Into Record / KR-SYS / KR* / KR-SYS User
              KR-KNS Look Up Records / KR-SYS / KR* / KR-SYS User
              KR-KNS Maintain Parameter / KR-SYS / KR* / KR-SYS Technical Administrator, KFS-SYS Manager
              KR-KNS Modify Batch Job / KR-SYS / KR* / KR-SYS Technical Administrator
              KR-KNS Open Document / KR-SYS / RiceDocument / KR-SYS User
              KR-SYS Use Screen / KR-SYS / KR* / none - we want peple to think about this when they add new custom action classes
          a responsibility for exception routing of RiceDocument was given to KR-SYS Technical Administrator

          TODO

          6. double check the permissions ailish listed in 5 above. note that KR-SYS User is a pass through role that anyone with an active principal gets (eric)

          7. implement KR-KNS permission checks (warren)

          8. implement KR-KEW permission and responsibility checks (eric)
            a. workflow should accept a KIM responsibility with template KR-KEW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type
            b. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
            format is template (attributes) - notes
              KR-KEW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
              KR-KEW Administer Routing for Document (Document Type) - this is super use permission
              KR-KEW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
              KR-KEW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
              KR-KEW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
              KR-KEW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
              KR-KEW Save Document (Document Routing Node & State) - this is an alternate for the policy

          9. all rice actions should extend KualiAction, so these permissions are enforced - they replace any existing app constants or configuration related to rice authz - please double check for any i missed (eric)
            format is template / permission namespace / permission details
              KR-SYS Use Screen / KR-KEW / org.kuali.rice.kew.documentoperation.web.DocumentOperationAction
              KR-SYS Use Screen / KR-KSB / org.kuali.rice.ksb.security.admin.web.JavaSecurityManagementAction
              KR-SYS Use Screen / KR-KSB / org.kuali.rice.ksb.messaging.web.MessageQueueAction
              KR-SYS Use Screen / KR-KSB / org.kuali.rice.ksb.messaging.web.ServiceRegistryAction
              KR-SYS Use Screen / KR-KSB / org.kuali.rice.ksb.messaging.web.ThreadPoolAction
              KR-SYS Use Screen / KR-KSB / org.kuali.rice.ksb.messaging.web.QuartzQueueAction

          10. enforce permissions for the first set of kim documents in the those - see the kfs/kim data mapping spreadsheet type tab (lin-long)
              KR-KIM Assign Role (this also applies to the delegations section of the document)
              KR-KIM Grant Permission
              KR-KIM Grant Responsibility
              KR-KIM Modify Entity
              KR-KIM Populate Group

          11. develop a data dictionary, property-based qualification resolver (warren)
          1. workflow should accept a KIM responsibility with template KR-KEW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type

          2. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
            format is template (attributes) - notes
              KR-KEW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
              KR-KEW Administer Routing for Document (Document Type) - this is super use permission
              KR-KEW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
              KR-KEW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
              KR-KEW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
              KR-KEW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
              KR-KEW Save Document (Document Routing Node & State) - this is an alternate for the policy
          Assignee Ailish Byrne [ abyrne ] Eric Westfall [ ewestfal ]
          Ailish Byrne made changes -
          Project KFS Maintenance & Infrastructure [ 10300 ] KRICE Development [ 10220 ]
          Key KFSMI-1814 KULRICE-2415
          Reviewed by Prioritization Committee No
          Rice Module [Rice Core, KSB, KNS, KEW, KEN, KCB, KIM, KOM]
          Requires Application Refactoring No
          Component/s Development [ 11244 ]
          Component/s Development [ 11760 ]
          Forced Change No
          Application Requirement [KFS, KRA, KS, KRICE]
          Responsible Team [Rice Team]
          Hide
          Ailish Byrne added a comment -

          as usual, feel free to assign to someone else

          Show
          Ailish Byrne added a comment - as usual, feel free to assign to someone else
          Ailish Byrne made changes -
          Fix Version/s 0.9.4 [ 13481 ]
          Due Date 2008-11-14 00:00:00.0 2008-11-07 00:00:00.0
          Ailish Byrne made changes -
          Link This issue is relied upon by KFSMI-1812 [ KFSMI-1812 ]
          Ailish Byrne made changes -
          Summary implement KR-KEW permission and responsibility checks (eric) implement KR-KEW permission and responsibility checks
          Eric Westfall made changes -
          Assignee Eric Westfall [ ewestfal ] Jeremy Hanson [ jjhanso ]
          Eric Westfall made changes -
          Link This issue relies on KULRICE-2414 [ KULRICE-2414 ]
          Ailish Byrne made changes -
          Description 1. workflow should accept a KIM responsibility with template KR-KEW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type

          2. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
            format is template (attributes) - notes
              KR-KEW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
              KR-KEW Administer Routing for Document (Document Type) - this is super use permission
              KR-KEW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
              KR-KEW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
              KR-KEW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
              KR-KEW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
              KR-KEW Save Document (Document Routing Node & State) - this is an alternate for the policy
          1. workflow should accept a KIM responsibility with template KR-WKFLW Resolve Exception Routing to define the set of people who should handle exception routing for a particular document type and route node (taking the document type hierarchy into account), in place of the specification of an exception workgroup on the document type

          2. workflow should enforce the following permission templates (attributes associated with the template type are in parens), and not require groups or policies be specified on the given document type when they are present
            format is template (attributes) - notes
              KR-WKFLW Ad Hoc Review Document (Document Type & Action Request Type) - this is permission to receive an ad hoc request
              KR-WKFLW Administer Routing for Document (Document Type) - this is super use permission
              KR-WKFLW Blanket Approve Document (Document Type) - this is the blanket approval workgroup
              KR-WKFLW Cancel Document (Document Routing Node & State) - this is an alternate for the policy
              KR-WKFLW Initiate Document (Document Type & Existing Records Only) - workflow ignores the existing records only piece
              KR-WKFLW Prepare & Route Document (Document Type) - this is an alternate for the initiator must route policy
              KR-WKFLW Save Document (Document Routing Node & State) - this is an alternate for the policy
          Ailish Byrne made changes -
          Summary implement KR-KEW permission and responsibility checks implement KR-WKFLW permission and responsibility checks
          Ailish Byrne made changes -
          Link This issue is related to KFSMI-1959 [ KFSMI-1959 ]
          Eric Westfall made changes -
          Assignee Jeremy Hanson [ jjhanso ] Eric Westfall [ ewestfal ]
          Hide
          Eric Westfall added a comment -

          As part of this, continue to support specification via the XML to ease migration and reduce impact.

          Code should check Document Type configuration first (for blanket approve group, etc.) then try KIM if it's not defined there. When checking the DocumentType configuration, it should consider the hierarchy where appropriate. In otherwords, I don't think it's a good idea to try and mix-and-match here. So if blanket approve workgroup is specified on some parent Document Type, it will use that instead of going against KIM. Only if blanket approve workgroup is not defined anywhere in the document type hiearchy will it attempt to resolve the KIM permission.

          Show
          Eric Westfall added a comment - As part of this, continue to support specification via the XML to ease migration and reduce impact. Code should check Document Type configuration first (for blanket approve group, etc.) then try KIM if it's not defined there. When checking the DocumentType configuration, it should consider the hierarchy where appropriate. In otherwords, I don't think it's a good idea to try and mix-and-match here. So if blanket approve workgroup is specified on some parent Document Type, it will use that instead of going against KIM. Only if blanket approve workgroup is not defined anywhere in the document type hiearchy will it attempt to resolve the KIM permission.
          Eric Westfall made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Eric Westfall added a comment -

          AIish, question about this part:

          KR-WKFLW Cancel Document (Document Routing Node & State) - this is an alternate for the policy

          Shouldn't this be Document Type and Document Routing Node? Not sure what "state" is referring to there. Thanks.

          Show
          Eric Westfall added a comment - AIish, question about this part: KR-WKFLW Cancel Document (Document Routing Node & State) - this is an alternate for the policy Shouldn't this be Document Type and Document Routing Node? Not sure what "state" is referring to there. Thanks.
          Hide
          Ailish Byrne added a comment -

          i'm not sure. state is route status. but maybe we should be using route node there instead? that would definitely offer more flexibility. with that and the save one, i was just thinking of the use cases... cancel/save only at initiation vs. allowing that when the doc is enroute too. kns currently doesn't allow cancelling or saving once the doc is enroute. as part of the move to kim it will start allowing saving while the doc is enroute. i think if we stick with state we're gonna have to have some translation like we are for ad hoc - where basically we consider I and S as the same, rather than having to put those perms in for both... just checking the perms i have for these now...

          sure enough - i actually did use route node
          KR-WKFLW Cancel Document KUALI N/A N/A KualiDocument, AdHoc KR-NS Document Editor
          KR-WKFLW Save Document KUALI N/A N/A KualiDocument KR-NS Document Editor, KR-SYS System User

          can't check the db at the moment, cause i'm not done setting up my computer, but you could double check that route note rather than route status is actually the attr defn associated with the type associated with those templates? sorry - this is probably something i caught but failed to update completely in all the impacted areas like this jira

          Show
          Ailish Byrne added a comment - i'm not sure. state is route status. but maybe we should be using route node there instead? that would definitely offer more flexibility. with that and the save one, i was just thinking of the use cases... cancel/save only at initiation vs. allowing that when the doc is enroute too. kns currently doesn't allow cancelling or saving once the doc is enroute. as part of the move to kim it will start allowing saving while the doc is enroute. i think if we stick with state we're gonna have to have some translation like we are for ad hoc - where basically we consider I and S as the same, rather than having to put those perms in for both... just checking the perms i have for these now... sure enough - i actually did use route node KR-WKFLW Cancel Document KUALI N/A N/A KualiDocument, AdHoc KR-NS Document Editor KR-WKFLW Save Document KUALI N/A N/A KualiDocument KR-NS Document Editor, KR-SYS System User can't check the db at the moment, cause i'm not done setting up my computer, but you could double check that route note rather than route status is actually the attr defn associated with the type associated with those templates? sorry - this is probably something i caught but failed to update completely in all the impacted areas like this jira
          Hide
          Eric Westfall added a comment -

          It looks like the KimType has all three of them. It's called "Document Type and Routing Node or State". Does that mean I should pass in all 3 of those as the permission details?

          Show
          Eric Westfall added a comment - It looks like the KimType has all three of them. It's called "Document Type and Routing Node or State". Does that mean I should pass in all 3 of those as the permission details?
          Hide
          Ailish Byrne added a comment -

          ok - yes - then they can be set up either way. but, i am happy to change this, if you think it doesn't make sense and we should just use doc type and route node.

          Show
          Ailish Byrne added a comment - ok - yes - then they can be set up either way. but, i am happy to change this, if you think it doesn't make sense and we should just use doc type and route node.
          Hide
          Eric Westfall added a comment -

          Seems fine to me to have support for using all 3. Seems that would offer the most flexibility.

          Show
          Eric Westfall added a comment - Seems fine to me to have support for using all 3. Seems that would offer the most flexibility.
          Eric Westfall made changes -
          Link This issue discovered KULRICE-2454 [ KULRICE-2454 ]
          Hide
          Eric Westfall added a comment -

          Implementation of this is committed. What following is a summary of the details regarding DocumentTypePermissionServiceImpl below, showing how KIM integration and backward compatibility was implemented:

          canBlanketApprove:

          • if blanket approve group or policy defined on Document Type, evaluates that (legacy solution) to determine permission
          • otherwise goes to KIM for authorization check

          canReceiveAdHocRequest (principal):

          • checks if permissions are assigned in KIM
          • if they are, evaluates permission in kim for the given principal
          • if KIM permissions are not defined, falls back to legacy behavior of always allowing adhoc request

          canReceiveAdHocRequest (group):

          • checks if permissions are assigned in KIM
          • if they are, loops over every principal in the group and executes permission check
          • if KIM permissions are not defined, falls back to legacy behavior of always allowing adhoc request

          canAdministerRouting (group):

          • if super user group defined on document type, evaluates membership in that group (legacy solution)
          • otherwise goes to KIM for authorization check

          canCancel/canSave:

          • both of these need to consider the current nodes on the document, there can be more than one for parallel docs!
          • first checks if initiatorMustSave/initiatorMustCancel document type policies are defined
          • if they aren't loops over all route node names passed in, for each node...
          • checks if permission is defined in KIM
          • if it is, returns result of evaluation kim permission
          • if it isn't continues with next route node name
          • if, any of the auth checks evaluates to "true", principal is authorized
          • if at least one permission is defined in KIM but none evaulate to true, false is returned
          • if no KIM permissions found or initiatorMustSave/Cancel policy is defined
          • execute policy check and return

          canInitiate:

          • if permission is defined in KIM, evaluate it
          • otherwise, anyone can initiate

          canRoute:

          • if initiateMustRoute document type policy is not defined
          • if KIM permission exists, evaluate and return
          • if policy is defined or no KIM permissions exist...
          • return evaluation of initiatorMustRoute policy
          Show
          Eric Westfall added a comment - Implementation of this is committed. What following is a summary of the details regarding DocumentTypePermissionServiceImpl below, showing how KIM integration and backward compatibility was implemented: canBlanketApprove: if blanket approve group or policy defined on Document Type, evaluates that (legacy solution) to determine permission otherwise goes to KIM for authorization check canReceiveAdHocRequest (principal): checks if permissions are assigned in KIM if they are, evaluates permission in kim for the given principal if KIM permissions are not defined, falls back to legacy behavior of always allowing adhoc request canReceiveAdHocRequest (group): checks if permissions are assigned in KIM if they are, loops over every principal in the group and executes permission check if KIM permissions are not defined, falls back to legacy behavior of always allowing adhoc request canAdministerRouting (group): if super user group defined on document type, evaluates membership in that group (legacy solution) otherwise goes to KIM for authorization check canCancel/canSave: both of these need to consider the current nodes on the document, there can be more than one for parallel docs! first checks if initiatorMustSave/initiatorMustCancel document type policies are defined if they aren't loops over all route node names passed in, for each node... checks if permission is defined in KIM if it is, returns result of evaluation kim permission if it isn't continues with next route node name if, any of the auth checks evaluates to "true", principal is authorized if at least one permission is defined in KIM but none evaulate to true, false is returned if no KIM permissions found or initiatorMustSave/Cancel policy is defined execute policy check and return canInitiate: if permission is defined in KIM, evaluate it otherwise, anyone can initiate canRoute: if initiateMustRoute document type policy is not defined if KIM permission exists, evaluate and return if policy is defined or no KIM permissions exist... return evaluation of initiatorMustRoute policy
          Hide
          Eric Westfall added a comment -

          Note that this required me to add new methods to the PermissionService:

          isPermissionAssigned
          isPermissionAssignedByTemplateName

          That allows me to detect if there are any permissions defined for the template I'm dealing with (I'm only using the second method listed above but I added the first for the sake of consistency) which facilitated implementation of backward compatibility in order to ease migration efforts.

          Show
          Eric Westfall added a comment - Note that this required me to add new methods to the PermissionService: isPermissionAssigned isPermissionAssignedByTemplateName That allows me to detect if there are any permissions defined for the template I'm dealing with (I'm only using the second method listed above but I added the first for the sake of consistency) which facilitated implementation of backward compatibility in order to ease migration efforts.
          Eric Westfall made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Eric Westfall added a comment -

          Whoops, missed exception routing on this Working on that now...

          Show
          Eric Westfall added a comment - Whoops, missed exception routing on this Working on that now...
          Eric Westfall made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Eric Westfall added a comment -

          Hmm, exception routing is going to be a bit more complicated. I'd like to leverage all of the code we have currently for Kim responsibility routing. Here's what I'm thinking which would provide a really flexible solution in my opinion:

          1) Allow for a sub process to be defined in the Document Type with a pre-defined name (say "exception")
          2) When the ExceptionRoutingService goes to put a document into exception routing it will...
          a) first check if there is an exception group defined, if there is route to that using the legacy mechanism
          b) if no exception group defined, execute the "exception" sub process (hierarchy should be searched for sub process). When that sub process completes, resume execution of original route path

          If neither of the 2 cases above succeeds, the document will end up in EXCEPTION status in the message queue. Ultimately, i think it would be nice to have some sort of default "template" document type out there where we could define the default exception routing process to route to the equivalent of workflow admin.

          The nice thing about the solution above is that it allows for someone to do something like implement a custom qualifier resolver for KIM to be able to do things like do exception routing based on campus code or something like that (that's a specific request I received in the past from one of our teams here at IU).

          Would that satisfy what KFS needs?

          Show
          Eric Westfall added a comment - Hmm, exception routing is going to be a bit more complicated. I'd like to leverage all of the code we have currently for Kim responsibility routing. Here's what I'm thinking which would provide a really flexible solution in my opinion: 1) Allow for a sub process to be defined in the Document Type with a pre-defined name (say "exception") 2) When the ExceptionRoutingService goes to put a document into exception routing it will... a) first check if there is an exception group defined, if there is route to that using the legacy mechanism b) if no exception group defined, execute the "exception" sub process (hierarchy should be searched for sub process). When that sub process completes, resume execution of original route path If neither of the 2 cases above succeeds, the document will end up in EXCEPTION status in the message queue. Ultimately, i think it would be nice to have some sort of default "template" document type out there where we could define the default exception routing process to route to the equivalent of workflow admin. The nice thing about the solution above is that it allows for someone to do something like implement a custom qualifier resolver for KIM to be able to do things like do exception routing based on campus code or something like that (that's a specific request I received in the past from one of our teams here at IU). Would that satisfy what KFS needs?
          Hide
          Ailish Byrne added a comment -

          one thing that worries me about your notes above. i think if the old way isn't done, the new way should be assumed. so, i'm not sure about checking if perms are defined in kim. we aren't dooing that elsewhere. you have to. and, for example, this doesn't match our data...

          canCancel/canSave:

          • both of these need to consider the current nodes on the document, there can be more than one for parallel docs!
          • first checks if initiatorMustSave/initiatorMustCancel document type policies are defined
          • if they aren't loops over all route node names passed in, for each node...
          • checks if permission is defined in KIM
          • if it is, returns result of evaluation kim permission
          • if it isn't continues with next route node name
            ...

          for the can save, we don't specify a node on the perm, cause they can save at any rouote node. but, maybe this means i have to have 2 perms - 1 for save when at ad hoc, aka pre-route and one for save when enroute?

          Show
          Ailish Byrne added a comment - one thing that worries me about your notes above. i think if the old way isn't done, the new way should be assumed. so, i'm not sure about checking if perms are defined in kim. we aren't dooing that elsewhere. you have to. and, for example, this doesn't match our data... canCancel/canSave: both of these need to consider the current nodes on the document, there can be more than one for parallel docs! first checks if initiatorMustSave/initiatorMustCancel document type policies are defined if they aren't loops over all route node names passed in, for each node... checks if permission is defined in KIM if it is, returns result of evaluation kim permission if it isn't continues with next route node name ... for the can save, we don't specify a node on the perm, cause they can save at any rouote node. but, maybe this means i have to have 2 perms - 1 for save when at ad hoc, aka pre-route and one for save when enroute?
          Hide
          Eric Westfall added a comment -

          The only issue is that KEW relies on defaults rather than requiring specification of all document type policies. So, for example, the default for "initiator must route" is "true". However, the person defining the document type doesn't have to specify that (and it doesn't get written to the policy table automatically in any way, the code handles the defaulting if no value is defined). Most documents types would not have explicitly set initiator must route to true. So, if I just went to KIM first, is authorized would always return "false". Then as soon as I put these changes in, no one would be able to route any documents, let alone initiate them (providing the kim permissions weren't defined ahead of time).

          Regarding save, that sounds fine to me. It indicated using the route node name in the description of this jira but it could just be out of sync as you mentioned earlier When I saw that I was thinking you might want to restrict who could save at certain nodes. I can remove the node part of it though. THanks.

          Show
          Eric Westfall added a comment - The only issue is that KEW relies on defaults rather than requiring specification of all document type policies. So, for example, the default for "initiator must route" is "true". However, the person defining the document type doesn't have to specify that (and it doesn't get written to the policy table automatically in any way, the code handles the defaulting if no value is defined). Most documents types would not have explicitly set initiator must route to true. So, if I just went to KIM first, is authorized would always return "false". Then as soon as I put these changes in, no one would be able to route any documents, let alone initiate them (providing the kim permissions weren't defined ahead of time). Regarding save, that sounds fine to me. It indicated using the route node name in the description of this jira but it could just be out of sync as you mentioned earlier When I saw that I was thinking you might want to restrict who could save at certain nodes. I can remove the node part of it though. THanks.
          Hide
          Eric Westfall added a comment -

          After discussion with Ailish, they would like a mechanism which disables the checking if a KIM permission is defined before using KIM. I will define a system parameter with the name KIM_PRIORITY_ON_DOC_TYP_PERMS_IND. If the system parameter does not exist then it will behave as if it's value was set to "N"

          Show
          Eric Westfall added a comment - After discussion with Ailish, they would like a mechanism which disables the checking if a KIM permission is defined before using KIM. I will define a system parameter with the name KIM_PRIORITY_ON_DOC_TYP_PERMS_IND. If the system parameter does not exist then it will behave as if it's value was set to "N"
          Eric Westfall made changes -
          Link This issue discovered KULRICE-2456 [ KULRICE-2456 ]
          Hide
          Eric Westfall added a comment -

          Moved exception routing piece to KULRICE-2456 so I can resolve this particular issue.

          Show
          Eric Westfall added a comment - Moved exception routing piece to KULRICE-2456 so I can resolve this particular issue.
          Eric Westfall made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ailish Byrne made changes -
          Link This issue is related to KFSMI-1959 [ KFSMI-1959 ]
          Eric Westfall made changes -
          Link This issue discovered KULRICE-2462 [ KULRICE-2462 ]
          Hide
          Eric Westfall added a comment -

          Based on a discussion in the KTI today, I changed the default of the system parameter so that it would behave as if it was set to "Y". That way once someone has converted they could completely remove the parameter from the database if they really wanted to (goal was to avoid clutter in this table I believe).

          Show
          Eric Westfall added a comment - Based on a discussion in the KTI today, I changed the default of the system parameter so that it would behave as if it was set to "Y". That way once someone has converted they could completely remove the parameter from the database if they really wanted to (goal was to avoid clutter in this table I believe).
          Hide
          Eric Westfall added a comment -

          Bulk change of all Rice 1.0 issues to closed after public release.

          Show
          Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.
          Eric Westfall made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Shem Patterson (Inactive) made changes -
          Workflow custom [ 59801 ] Copy of custom for rice [ 210418 ]
          Shem Patterson (Inactive) made changes -
          Workflow Copy of custom for rice [ 210418 ] custom [ 220166 ]
          Shem Patterson (Inactive) made changes -
          Workflow custom [ 220166 ] Rice Workflow [ 229914 ]

            People

            • Assignee:
              Eric Westfall
              Reporter:
              Ailish Byrne
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Structure Helper Panel