CouchDB
  1. CouchDB
  2. COUCHDB-1307

Error popup when viewing futon on a vhost

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Futon
    • Labels:
    • Skill Level:
      New Contributors Level (Easy)

      Description

      When accessing futon from a vhost (where "/" doesn't return a json description of the server), you unnecessarily get an "error" popup (containing the entire html of the "/" page).
      Since many CouchApps link into futon as a way for end users to edit their profiles, they get the impression that the app is "broken".

        Activity

        Hide
        The Dod added a comment -

        I'd like to address the second issue you've raised first, because it's much more critical: You can't disable a user's ability to change own profile, and the current "de facto standard" (i.e. what you get from "couchapp generate" and therefore - 99% of the couchapverse) is that "edit profile" is a link to /_utils/document.html?_users/org.couchdb.user:myusername
        Even if in the future a non-futon solution for "edit profile" emerges, we'd still have to leave a clue to users of legacy couchapps there (it's acceptable if they get a warning or two along the way, but we'd still need a "we've moved here" link somewhere).

        Now for the issue of "treating any error case as a possible vhost": we're taking about a specific case. The function that might "fail" here is discovering the server's version. If the error is a result of something more serious than "we're on a vhost", then other alerts would (or at least should) trigger. All we need is to change the comment in the code "either it's a vhost, or things are so bad user has already figured out there's a problem and doesn't need yet another popup right now"

        A more elegant way to solve this would be to use a vhost-agnostic /_version or something instead of / for fetching the version, but my patch works on localhost. The fact that I don't have it at - say - iriscouch (because it's not "official") is frightening my users, so pretty please - either do it properly (/_version) or accept this simple and harmless patch so that they can relax.

        Show
        The Dod added a comment - I'd like to address the second issue you've raised first, because it's much more critical: You can't disable a user's ability to change own profile, and the current "de facto standard" (i.e. what you get from "couchapp generate" and therefore - 99% of the couchapverse) is that "edit profile" is a link to /_utils/document.html?_users/org.couchdb.user:myusername Even if in the future a non-futon solution for "edit profile" emerges, we'd still have to leave a clue to users of legacy couchapps there (it's acceptable if they get a warning or two along the way, but we'd still need a "we've moved here" link somewhere). Now for the issue of "treating any error case as a possible vhost": we're taking about a specific case. The function that might "fail" here is discovering the server's version. If the error is a result of something more serious than "we're on a vhost", then other alerts would (or at least should) trigger. All we need is to change the comment in the code "either it's a vhost, or things are so bad user has already figured out there's a problem and doesn't need yet another popup right now" A more elegant way to solve this would be to use a vhost-agnostic /_version or something instead of / for fetching the version, but my patch works on localhost. The fact that I don't have it at - say - iriscouch (because it's not "official") is frightening my users, so pretty please - either do it properly (/_version) or accept this simple and harmless patch so that they can relax.
        Hide
        Jan Lehnardt added a comment -

        I agree that this is a usability issue, but I don't think treating any error case as a possible vhost is the the right approach.

        I'd be happy to go on record to say that for the time being vhosts/rewrites don't support Futon (or vice versa) until we find a way to get this fixed.

        Show
        Jan Lehnardt added a comment - I agree that this is a usability issue, but I don't think treating any error case as a possible vhost is the the right approach. I'd be happy to go on record to say that for the time being vhosts/rewrites don't support Futon (or vice versa) until we find a way to get this fixed.
        The Dod made changes -
        Field Original Value New Value
        Attachment futon.js.diff [ 12498985 ]
        The Dod created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            The Dod
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 5m
              5m
              Remaining:
              Remaining Estimate - 5m
              5m
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development