Details

    • Similar issues:
      KULRICE-2252Migrate KEW field-level help to use KRAD help system
      KULRICE-3958Enable field level help to be turned on for individual maintenance document fields
      KULRICE-4707Hover over field level help with Dialog
      KULRICE-10507ENABLE_FIELD_LEVEL_HELP_IND in KualiForm
      KULRICE-1927Field level help-to be consistent with KFS should only have page level help
      KULRICE-2493Implement field-level security for maintenance documents
      KULRICE-3216Field level Help screens are missing for a number of data elements
      KULRICE-4808field level help button on email notification action list preference doesn't work
      KULRICE-4735Externalize labels from DD
      KULRICE-12960Make to/from methods on ServiceInfoBo public
    • Rice Module:
      KNS
    • Application Requirement:
      KFS

      Description

      On the KFS side:
      considered a bug, since the functional folks never requested this, and it has in fact been ruled against by them twice and by the usability / accessibility team. see linked issue

      On the Rice side:
      Need basic DD help as an option for client apps that may use rice to develop

      Solution:
      Keep everything as is in the KNS, except, have a new property flag that will turn the help icons on or off. This won't pre-clude anyone from using it and allows KFS and KRA to continue using the NetHelp system via SystemParam integration links for the help.

        Issue Links

          Activity

          Hide
          Aaron Godert (Inactive) added a comment -

          Does this mean that they will not expect to be able to see both the data type and length for a field? Or will that be stored in the User Guide?

          Show
          Aaron Godert (Inactive) added a comment - Does this mean that they will not expect to be able to see both the data type and length for a field? Or will that be stored in the User Guide?
          Hide
          Aaron Godert (Inactive) added a comment -

          Also, are we sure that this is not something that KRA needs?

          Show
          Aaron Godert (Inactive) added a comment - Also, are we sure that this is not something that KRA needs?
          Hide
          Ailish Byrne added a comment -

          according to geoff (at the dm meeting yesterday), they stopped using field level help for kra in kfs a while ago. i think we need to hear from the kra app team when we review the proposal tomorrow. also, i suspect we won't really know the answer to that until scott presents the kfs strategy to the kra functional folks at the meeting up in indy in a couple of weeks. but, it would be easy enough to make this turn on and offable in terms of the ns stuff. they are not interested in seeing the data type info that's currently being presented based on dd validation config, e.g. AnyCharacter. In cases where they don't think the data type is immediately obvious based on the field descr, that info will be added to the field descr. In terms of the max length, I think they're just saying they don't need that ifno since the user can get it just by submitting the page or typing in the field. basically the feeling is that this type of help might be useful the first couple times a user uses a page but not after. and, they feel like they can get sufficient info in the page level help.

          Show
          Ailish Byrne added a comment - according to geoff (at the dm meeting yesterday), they stopped using field level help for kra in kfs a while ago. i think we need to hear from the kra app team when we review the proposal tomorrow. also, i suspect we won't really know the answer to that until scott presents the kfs strategy to the kra functional folks at the meeting up in indy in a couple of weeks. but, it would be easy enough to make this turn on and offable in terms of the ns stuff. they are not interested in seeing the data type info that's currently being presented based on dd validation config, e.g. AnyCharacter. In cases where they don't think the data type is immediately obvious based on the field descr, that info will be added to the field descr. In terms of the max length, I think they're just saying they don't need that ifno since the user can get it just by submitting the page or typing in the field. basically the feeling is that this type of help might be useful the first couple times a user uses a page but not after. and, they feel like they can get sufficient info in the page level help.
          Hide
          Aaron Godert (Inactive) added a comment -

          See description for final approach on performing this task.

          Show
          Aaron Godert (Inactive) added a comment - See description for final approach on performing this task.
          Hide
          Aaron Godert (Inactive) added a comment -

          Just tagging with 0.9.0.2 top level version.

          Show
          Aaron Godert (Inactive) added a comment - Just tagging with 0.9.0.2 top level version.
          Hide
          Warren Liang added a comment -

          I have several questions:

          1) The field level help is the help page that derives its content from the DD and not from external html files, right?

          2) Does this issue refer to the field-level help that is rendered on maint docs and lookup screens only? If some transactional doc explicitly renders a field-level help, am I to get rid of it?

          3) Is the "property flag" to which you're referring a global app-wide parameter that turns on or off the help icons? Or, were you envisioning specifying on each BO or maint doc DD definition whether field level help icons were needed?

          4) If the property flag is a global flag, do we need a way for each BO to override the global setting using the DD?

          Thanks.

          Show
          Warren Liang added a comment - I have several questions: 1) The field level help is the help page that derives its content from the DD and not from external html files, right? 2) Does this issue refer to the field-level help that is rendered on maint docs and lookup screens only? If some transactional doc explicitly renders a field-level help, am I to get rid of it? 3) Is the "property flag" to which you're referring a global app-wide parameter that turns on or off the help icons? Or, were you envisioning specifying on each BO or maint doc DD definition whether field level help icons were needed? 4) If the property flag is a global flag, do we need a way for each BO to override the global setting using the DD? Thanks.
          Hide
          Warren Liang added a comment -

          Per Ailish:

          1) Yes, DD-based help pages

          2) Maint doc and lookup screens. An issue will be created later for teams to determine clean up any transactional docs that use field-level help.

          3) The property flag is a global app-wide parameter.

          4) No DD-based overrides will be provided in this release.

          Also, the <summary> and <description> fields will become optional in the DD DTD file, since field level help isn't required anymore

          Thanks Ailish .

          Show
          Warren Liang added a comment - Per Ailish: 1) Yes, DD-based help pages 2) Maint doc and lookup screens. An issue will be created later for teams to determine clean up any transactional docs that use field-level help. 3) The property flag is a global app-wide parameter. 4) No DD-based overrides will be provided in this release. Also, the <summary> and <description> fields will become optional in the DD DTD file, since field level help isn't required anymore Thanks Ailish .
          Hide
          Ailish Byrne added a comment -

          specifically, summary and description were made optional on the following...

          • attribute
          • attributeReference
          • collection
          • maintenanceDocument
          • transactionalDocument
          Show
          Ailish Byrne added a comment - specifically, summary and description were made optional on the following... attribute attributeReference collection maintenanceDocument transactionalDocument

            People

            • Assignee:
              Warren Liang
              Reporter:
              Jerry Neal (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Structure Helper Panel