Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-10772

Support "Use Transactional Document" permission in KRAD

    Details

    • Epic Link:
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Maintenance
    • Application Requirement:
      Rice
    • Sprint:
      2.5.0-m2 Sprint 3
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Support for a "Use Transactional Document" permission which was used to control the availability of various sections/features of the document. One of the permission details was an "editMode", which predates the KIM conversion. It was a simple string flag which was stored in the request and checked by the JSP code (and business rules) to determine what the user could do with the document at the present time.

      This feature was also used to present completely different views on a few KFS documents.
      Line item 1 on https://docs.google.com/a/kuali.org/spreadsheet/ccc?key=0AqaSaSLMsdRMdGUxREo4UXRBN1FjN1Fyb1Bvb3JhWUE#gid=0

        Attachments

          Issue Links

            Activity

            Hide
            christieheitkamp Christie Heitkamp (Inactive) added a comment - - edited

            When this is implemented in the UI, UXI recommends also adding an indication of what kind of mode the user is in so the user may be able to determine why they can or cannot edit or view certain things... this may be as simple as displaying a message at the top of the screen stating that some fields may not be editable due to permissions.

            We could also indicate those fields with a symbol if it is possible. For example, fields marked with a '**" are only editable by someone with <insert permission level here> permissions.

            Show
            christieheitkamp Christie Heitkamp (Inactive) added a comment - - edited When this is implemented in the UI, UXI recommends also adding an indication of what kind of mode the user is in so the user may be able to determine why they can or cannot edit or view certain things... this may be as simple as displaying a message at the top of the screen stating that some fields may not be editable due to permissions. We could also indicate those fields with a symbol if it is possible. For example, fields marked with a '**" are only editable by someone with <insert permission level here> permissions.
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            Few notes on this. One, I believe there is logic in the base view authorizer and presentation controller for edit modes, however, I am not sure it is looked at the document permission. Also note, the View has a property for edit modes and action flags. You can see this in use in the bean Uif-DocumentFooter.

            We should create a lab for this with some various edit modes.

            Also, as part of these, please check the UIF component permissions are still working correctly. There is a page in the Kitchen Sink for testing this. We should move these examples to a demo (in General Features).

            Show
            jkneal Jerry Neal (Inactive) added a comment - Few notes on this. One, I believe there is logic in the base view authorizer and presentation controller for edit modes, however, I am not sure it is looked at the document permission. Also note, the View has a property for edit modes and action flags. You can see this in use in the bean Uif-DocumentFooter. We should create a lab for this with some various edit modes. Also, as part of these, please check the UIF component permissions are still working correctly. There is a page in the Kitchen Sink for testing this. We should move these examples to a demo (in General Features).

              People

              • Assignee:
                jheckel Jeff Heckel (Inactive)
                Reporter:
                jruch Jeff Ruch
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 3 days
                  3d
                  Remaining:
                  Time Spent - 1 day, 4 hours Remaining Estimate - 1 day, 4 hours
                  1d 4h
                  Logged:
                  Time Spent - 1 day, 4 hours Remaining Estimate - 1 day, 4 hours
                  1d 4h