Loading...

Default return behavior from qListForm – fixed?

Default return behavior from qListForm – fixed?

  • This topic is empty.
Viewing 1 reply thread
  • Author
    Posts
    • #3924
      Anonymous
      Anonymous
      Participant

      Not a problem to report – I just want to confirm a pleasant surprise. It appears that a nuisance with form web parts has been fixed, although I cannot find the fix mentioned in the release notes for 5.1 or 5.2. I am sure I remember that earlier this year, the following scenario was true: 1. create a web part page with a qListView against list X 2. create qListForms for Create/Read/Update forms for List X 3. from the web part page in #1 above, open one of the items in X – any mode – Create, Read or Update. 4. from the qListForm, click Cancel. 5. the user is taken not back to the web part page, but to the All items view for list X. I worked with our Quest consultant to begin understanding how to configure the redirect options on qListForm to deal with this. It was really a confusing process, since coming up with the correct URL is always tricky. We are now at 5.2. I went to document the above issues for our development group, but now the behavior appears to be correct by default. At step 5, the user is taken back to the source web part page instead of to the All Items view page. This is certainly a good thing; am I imagining that this was ever a problem, or has it been fixed and just not documented anywhere? I just want to make sure something really has been changed before I report it as no longer an issue that has to be handled by the developer. Thanks!

    • #5147
      Anonymous
      Anonymous
      Participant

      I am not aware of the issue as described above. By default, the proper behavior is that Cancel button from qListForm should always redirect it to the source web part page.

      When you are taken to the qListForm page from qListView, either by using Create/View/Edit menu, you can check the URL address bar and notice there is query string Source. The value to this parameter is where we would consider going when Cancel button is clicked, depending on the propery "Cancel Button Click Action" settings you select, such as "GoToSource" or "TrySourceThenGoBackUrl".

      Could it be that the "Go Back Url" property is set in your previous scenario that points to allitem page?

Viewing 1 reply thread

You must be logged in to reply to this topic.