Details

    • Type: Sub Task Sub Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0, 1.0.1, KFS Release 3.0
    • Fix Version/s: 1.0.1
    • Component/s: User Interface
    • Labels:
      None
    • Similar issues:
      KULRICE-4062Add support for longer html tags in question text
      KULRICE-11437Verify that XSS protection fix hasn't disabled HTML support in tooltip help
      KULRICE-7969Uif-DataField doesn't understand html tags
      KULRICE-4478HTML padded with spaces breaking hyperlink
      KULRICE-7512Fix Schema Spy link from portal.html
      KULRICE-5437UIF Framework - Add standard markup for table semantics
      KULRICE-3448Fix principal Ids in KREN tables
      KULRICE-7985Problems with tables within divs and filling past the div container
      KULRICE-2540Fix UniversityIdRoleAttributeTest
      KULRICE-9784Add json sorting functionality to light table the same way it is done for the standard table json feature
    • Rice Module:
      KEW
    • Application Requirement:
      Rice

      Description

      Currently the screens look odd when displaying multiple columns. The html is not properly rendering the tables. Please clean up the table column widths. For an example of how it could look, refer to the old kfs testdrive environment.

        Issue Links

          Activity

          Hide
          Chad Hagstrom added a comment -

          My investigations have also revealed some other problematic lookupable helper services whose getRows() methods perform field addition/deletion operations which assume that rows only have one column:

          GroupLookupableHelperServiceImpl.getRows()
          RoleLookupableHelperServiceImpl.getRows()
          RoleMemberLookupableHelperServiceImpl.getRows() (although the "detailCriteria" field that it tries to modify or remove does not appear to be present in its associated data dictionary XML file)
          PessimisticLockLookupableHelperServiceImpl.getRows() (although the problematic row removal code never gets executed for pessimistic lock admin users)

          I believe these getRows() methods need fixing in order for their respective lookups to display and function properly, regardless of the number of columns chosen.

          Show
          Chad Hagstrom added a comment - My investigations have also revealed some other problematic lookupable helper services whose getRows() methods perform field addition/deletion operations which assume that rows only have one column: GroupLookupableHelperServiceImpl.getRows() RoleLookupableHelperServiceImpl.getRows() RoleMemberLookupableHelperServiceImpl.getRows() (although the "detailCriteria" field that it tries to modify or remove does not appear to be present in its associated data dictionary XML file) PessimisticLockLookupableHelperServiceImpl.getRows() (although the problematic row removal code never gets executed for pessimistic lock admin users) I believe these getRows() methods need fixing in order for their respective lookups to display and function properly, regardless of the number of columns chosen.
          Hide
          Chad Hagstrom added a comment -

          I've nearly finished the necessary modifications to the lookupable helper services to make their custom getRows() processing compatible with the multi-column functionality. Before finishing this portion of the issue up, however, I noticed that RoleLookupableHelperServiceImpl contains a private setupAttributeRows() method that does not get used locally, since its one and only call in getRows() has been commented out. Should this method just be removed, then? If not, then I will need to modify it so that it becomes multi-column compatible.

          I've also discovered another issue. Since the routing rule lookup (and probably the rule delegate lookup as well) can retrieve extra lookup fields based on the rule attributes of the specified rule template (if any), should the rule attributes be modified to conform to the new multi-column functionality, or should the extra fields remain in separate rows?

          Show
          Chad Hagstrom added a comment - I've nearly finished the necessary modifications to the lookupable helper services to make their custom getRows() processing compatible with the multi-column functionality. Before finishing this portion of the issue up, however, I noticed that RoleLookupableHelperServiceImpl contains a private setupAttributeRows() method that does not get used locally, since its one and only call in getRows() has been commented out. Should this method just be removed, then? If not, then I will need to modify it so that it becomes multi-column compatible. I've also discovered another issue. Since the routing rule lookup (and probably the rule delegate lookup as well) can retrieve extra lookup fields based on the rule attributes of the specified rule template (if any), should the rule attributes be modified to conform to the new multi-column functionality, or should the extra fields remain in separate rows?
          Hide
          Chad Hagstrom added a comment -

          In addition to the problems mentioned in my previous post and my earlier-mentioned "docRouteNodeId" issue, I've found something else that may need fixing as well. On the doc search, if the "clear" button is clicked and a doc type is specified in the search criteria, then one of the methods that eventually gets called is DocumentLookupCriteriaProcessorKEWAdapter.standardNonSearchAttRows, which generates rows containing only one field each, even if multiple columns are specified. This results in improper generation of the displayed search field table when the clearing operation finishes. Should this method (and the relevant methods that call it) also be modified to support the multi-column functionality?

          Show
          Chad Hagstrom added a comment - In addition to the problems mentioned in my previous post and my earlier-mentioned "docRouteNodeId" issue, I've found something else that may need fixing as well. On the doc search, if the "clear" button is clicked and a doc type is specified in the search criteria, then one of the methods that eventually gets called is DocumentLookupCriteriaProcessorKEWAdapter.standardNonSearchAttRows, which generates rows containing only one field each, even if multiple columns are specified. This results in improper generation of the displayed search field table when the clearing operation finishes. Should this method (and the relevant methods that call it) also be modified to support the multi-column functionality?
          Hide
          Garey Taylor added a comment -

          Hi Chad,

          So from our meeting today it seems that this is good to go if the standard KNS lookup works with multi columns. If that's the case then I will create a new JIRA to address the multi-column clear issue on the doc search.

          Thanks for working on this one.

          Show
          Garey Taylor added a comment - Hi Chad, So from our meeting today it seems that this is good to go if the standard KNS lookup works with multi columns. If that's the case then I will create a new JIRA to address the multi-column clear issue on the doc search. Thanks for working on this one.
          Hide
          Chad Hagstrom added a comment - - edited

          I've finished commiting the fixes for the person, group, role, role member (permission and responsibility), and pessimistic lock lookupable helper services, so they should all be multi-column compatible now, at least for their current configurations. I've also verified that the revert-to-single-column problem with the "clear" button is a doc-search-specific problem. However, there are still some column-related problems that will need to be addressed in a future release:

          [1] The doc search experiences some problems when in multi-column mode, such as the "clear" button issue mentioned above and a certain drop-down that leaves a blank spot in one of the multi-column rows when no doc type is specified.

          [2] The routing rule lookup (and possibly the rule delegate lookup) currently displays rule-attribute-related fields in individual rows, even when in multi-column mode.

          [3] I've left the unused "setupAttributeRows" method on RoleLookupableHelperServiceImpl as-is for now, so this should either be removed or made multi-column compatible accordingly.

          Show
          Chad Hagstrom added a comment - - edited I've finished commiting the fixes for the person, group, role, role member (permission and responsibility), and pessimistic lock lookupable helper services, so they should all be multi-column compatible now, at least for their current configurations. I've also verified that the revert-to-single-column problem with the "clear" button is a doc-search-specific problem. However, there are still some column-related problems that will need to be addressed in a future release: [1] The doc search experiences some problems when in multi-column mode, such as the "clear" button issue mentioned above and a certain drop-down that leaves a blank spot in one of the multi-column rows when no doc type is specified. [2] The routing rule lookup (and possibly the rule delegate lookup) currently displays rule-attribute-related fields in individual rows, even when in multi-column mode. [3] I've left the unused "setupAttributeRows" method on RoleLookupableHelperServiceImpl as-is for now, so this should either be removed or made multi-column compatible accordingly.

            People

            • Assignee:
              Chad Hagstrom
              Reporter:
              Garey Taylor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel