Conference orarep::nomahs::rally

2923.0. "Disable Rally Required Field Visitation Feature" by ORAREP::JRFVAX::FREDRICKSON (Rallyho lads!) Tue Feb 11 1997 13:41

    ...I'm posting this here to get feedback from other Rally sites...
    
    We had a meeting yesterday with reps from the development and user
    communities about going forward with V7.0.  Everything looks good
    except for one major behavioral change: the visitation aspect of
    Required Field checking.
    
    In our environment, the user can visit child groups early on a screen
    and then revisit the parent to fill in additional required fields.  We
    didn't have the luxury of deferring the child group visitation until
    all of the parent required fields are filled in.  There are a lot of
    screens that fit this scenario.
    
    Up to this point, we were able to emulate RALLY 'natural' Required
    Field check with ADL procedure checking at the Before-Commit Action
    Site.  Our screens therefore became a mixture of RALLY and procedure
    checking.  Whether it be RALLY or the ADL that catches it, the user
    gets the same error message - "one or more required fields were left
    blank...".
    
    Well, with the new behavior change of Required Fields, our management
    raised the red flag that now the user would see a "split personality"
    in our screens.  If they failed to fill in a RALLY-tagged required
    field, then they would get the error message and RALLY would take them
    to that field.  If they failed to fill in an ADL-validated required
    field, then they would get the error message but the cursor would stay
    right where they were (ala pre-V7.0).  Since the "set_current_field"
    wasn't set up to work off of the Before-Commit action site, we can't
    move the cursor ala V7.0 behavior.  Needless to say, our concern is
    that our users would be confused and demand the behavior be consistent,
    one way or the other.
    
    I must say that, given engineering's aversion to addressing behavior
    change issues (see V6.1 Release Notes Section 1.16), we were surprised
    that there wasn't offered some means of disabling this feature so that
    sites like ours could still emulate the pre-V7.0 behavior.
    
    Now, I must apologize for not catching this during our field test, but
    it was my impression that the user community down here would be OK with
    the mixed behavior setup and I really didn't give it much thought.
    
    I've been asked to communicate to you that the RALLY community down
    here wants this issue addressed.  As I see it, there are three possible
    solutions, with the first one probably being the easiest to implement
    on your part and the least amount of retrofitting on our part:
    
    	1) A Logical or switch to disable the new Required Field 
    	   visitation behavior.  This would be similar to the logical to 
    	   disable the Working message.  Setting this switch would revert 
    	   behavior back to pre-V7.0 style.
    
    	2) Allow set_current_field to work at the Before-Commit action site.
    
    	3) Tie the Required Field check to the Defer Update check such that
    	   RALLY would know that it doesn't need to validate until it senses
    	   that it an attempt is underway to send the data to the database.
    
    My personal preference is #3, since this would eliminate the need for
    procedure checks and would get the Required Field check in line with
    RALLY's timing to the database.  Not to diverge, but #3 would also
    have to defer the check on the Before/After Insert and Update action
    sites as well.
    
    The management here would like have a response as to your perception on
    this issue.  For what it's worth, if solution #1 is the most viable,
    then what would be the possibility of addressing it as a MUP versus a
    feature in the new release?  At this point in time, this appears to be
    the one sticking point in going forward with RALLY V7.0.  I'm not
    saying that it's dead in the water, but an assurance from engineering
    that this concern will be addressed in a release in the very near
    future might be enough to push it through.

    steve,
    
     I hear you. BTW, Will Anderson is no longer with Oracle, I've taken
    on the Rally engineering manager's role.
    
    We just completed an eco for rally v7 and all our energies are focused
    on getting the rally to developer 2000 beta ready for march.
    
    i'm in california this week and next week i'll sit down with the
    engineers and see how we can approach this.
    
    i'll post an answer here next week.
    
    
    thanks
    
    steve 

    Steve,
    
    Thanks for the quick response.  Mark Sullivan has my phone number and
    I'm pretty close to my desk these days, so feel free to give me a call
    if you have any questions re: this issue.
    
    Steve
    
    P.S. ...great first name, by the way!