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

DocumentTypePermissionTypeServiceImpl should be in the org.kuali.rice.kew package structure and not org.kuali.rice.kns

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-9999Refactor package structure in krad-data module such that jpa is not under "provider" package
      KULRICE-3710impex-build.properties.sample in packaged impex tool needs better values
      KULRICE-11636Rename QueryCustomizer to Filter and move from eclipselink package to jpa package
      KULRICE-13836Rename test package structure to better align with dev structure
      KULRICE-631Refactor package structure to be in line with the rest of Rice
      KULRICE-10176Breadcrumb classes should be moved out of util package and into elements package
      KULRICE-3413Add dataset packaging to the Rice packaging scripts
      KULRICE-1385Create an assembly for a binary package
      KULRICE-3419Do some general cleanup on project structure and get rid of uneeded files
      KULRICE-11957Move ProviderRegistrationFactory to krad.data.provider package and change name to ProviderRegistrar
    • Rice Module:
      KNS, KEW

      Description

      This class is using the DocumentTypeService and other internal KEW pieces, it should be moved to the org.kuali.rice.kew.service.impl package. We also need to ensure it gets updated in any spring configuration files (i.e. may need to be moved from KNSSpringBeans.xml to KEWSpringBeans.xml if not already and package name updated).

        Activity

        Hide
        Ailish Byrne added a comment -

        i disagree. it is also being used for a number of kns related permissions. ideally it would be in core where document type will go. if possible, i'd like to leave this alone at this point, since i don't see moving to kew as being any better than it being in kns, and it requires a data change?

        Show
        Ailish Byrne added a comment - i disagree. it is also being used for a number of kns related permissions. ideally it would be in core where document type will go. if possible, i'd like to leave this alone at this point, since i don't see moving to kew as being any better than it being in kns, and it requires a data change?
        Hide
        Eric Westfall added a comment -

        Ok, we can leave it alone if we need to, it's certainly low priority it just came up in a conversation earlier today so I wanted to capture it. Just seems like it's directly related to Document Type and accesses KEW services and nothing else the Document Type service so should be hosted out of the KEW module. Out of curiosity, what is the data change that would be required?

        Show
        Eric Westfall added a comment - Ok, we can leave it alone if we need to, it's certainly low priority it just came up in a conversation earlier today so I wanted to capture it. Just seems like it's directly related to Document Type and accesses KEW services and nothing else the Document Type service so should be hosted out of the KEW module. Out of curiosity, what is the data change that would be required?
        Hide
        Ailish Byrne added a comment -

        i just think it's a little weird to start moving stuff to kew when it relates to document type, when we said document type belongs in core in the long run. i'm a dummy and no data change cause the service name would remain the same, so i guess i don't care. sorry

        Show
        Ailish Byrne added a comment - i just think it's a little weird to start moving stuff to kew when it relates to document type, when we said document type belongs in core in the long run. i'm a dummy and no data change cause the service name would remain the same, so i guess i don't care. sorry
        Hide
        Ailish Byrne added a comment -

        btw - all it cares about is the doc type hierarchy right? not routing. so, i would assume the doc type hierarchy would be a core concept when doc type moves to core. anyway, again. i don't really care about what package it's in. just theoretical comments

        Show
        Ailish Byrne added a comment - btw - all it cares about is the doc type hierarchy right? not routing. so, i would assume the doc type hierarchy would be a core concept when doc type moves to core. anyway, again. i don't really care about what package it's in. just theoretical comments
        Hide
        Eric Westfall added a comment -

        Will re-examine this in a later release.

        Show
        Eric Westfall added a comment - Will re-examine this in a later release.
        Hide
        David Elyea added a comment -

        Can we add the PermissionDerivedRoleTypeServiceImpl class to this? I think it's the exact same situation except that it only relies on the KIM module (where the document type service relies on KIM and KEW).

        Also, i'm not sure if there are any more classes that might be part of this so maybe it should be more of a general investigation type task.

        Show
        David Elyea added a comment - Can we add the PermissionDerivedRoleTypeServiceImpl class to this? I think it's the exact same situation except that it only relies on the KIM module (where the document type service relies on KIM and KEW). Also, i'm not sure if there are any more classes that might be part of this so maybe it should be more of a general investigation type task.

          People

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

            Dates

            • Created:
              Updated:

              Structure Helper Panel