From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields‎ | Status
    This page contains changes which are not marked for translation.

    Purpose of this Page

    This page is about the RESOLVED state of the Status Field in Bugzilla. It is dedicated to explaining and clarifying the purpose of the multiple RESOLVED states as well as describing the steps which QA can/will take in addressing RESOLVED bugs.

    The Meaning of RESOLVED

    There are a bunch of sub-states for RESOLVED:


    This bug has been fixed by a particular commit. There should be one or more target:<LO version X.y.z> tags in the Whiteboard, each of which indicates a version/branch of LibreOffice in which this commit will be included.


    • 'Blue 1' is set to the same color as 'Sky Blue 1' - tdf#86511
      • Whiteboard: target:4.5.0 target:

    If you do not know which commit fixed a bug -- use RESOLVED WORKSFORME instead.

    For automated gathering of statistics, it is better to let the bug fixer change the resolution to FIXED. Either give the developer time to do it or politely ask them to change it, if they did not do it in a timely manner. It is fine to change additional bugs discovered fixed by a commit to FIXED right away, if it is more fitting than closing as DUPLICATE.


    Something about this bug report is invalid or does not compute. For example if someone files a report like this, we'd resolve it as INVALID:

     I am a walrus
     I am a walrus and I think everyone should know. The repro steps are eating fish.

    Previously, we'd use the RESOLVED INVALID status as a catch-all for various families of bugs, including bugs that had sat in NEEDINFO state for over half a year, and that we wanted to set aside. Now we have the #INSUFFICIENTDATA status which is a better fit for those categories of bugs.


    This may be a bug, but we aren't planning to fix it for some reason (which is usually detailed in a comment when the bug is resolved as WONTFIX). Examples include:

    • A bug that doesn't affect any actual users


    This bug is a duplicate of another bug already in the system.

    Please don't use this value if the same person has reported the exact same issue twice, as this would skew our metrics. Instead, close the duplicate(s) as "INVALID".


    In shorthand, WORKSFORME is written "WFM".

    Someone in QA has tested this bug using the provided steps and/or test documents, could reproduce it in an older version, but can't anymore in a current version. If the commit that solved the problem is known, then the status should rather be FIXED.

    Same reproduction environment

    If you have the same environment as the bug reporter (e.g. same OS, same version of LibreOffice), we feel a lot more confident about marking a bug as WFM. If you don't have the same environment (e.g. same LO version, but they're on Windows and you're on macOS), see if someone in the QA/IRC channel has the same environment and can double-check your work.

    The decision to close a bug as WFM without feedback from the original reporter or confirmers is done on a case by case basis. Normally it is good to give others some time to test. The age of the report and its last confirmation should be taken into consideration.

    The reason a bug is WFM in the same reproduction environment could be that the user profile was corrupt. Make sure to ask the bug reporter to test LibreOffice in Safe Mode and see if resetting the user profile (after backup) resolves their issue.

    Fixed in a newer version

    If a bug is gone in master but not in one of the currently maintained release branches (see our release plan), the bug is considered resolved. If we don't know which precise commit solved the bug, we'll mark the bug as WFM; if the commit is known, we'll mention the commit in a comment and mark the bug as FIXED.


    • tdf#74300 - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
    • tdf#79289 - FILEOPEN: DOCX shapes turn to frames and fill background not retained

    If we know which commit fixed the problem, it's fine to ask the author (developer) if it's possible to backport the fix. If we don't know which commit fixed the bug, we need to figure that out. We can add the keyword bibisectRequest and add to the whiteboard backportRequest:<active branch>. This will indicate that we need to do a "reverse" bibisect (to figure out when the bug was fixed, instead of when the bug was introduced).

    Example whiteboard:

     backportRequest:4.2 backportRequest:4.3
    Note pin.svg

    Before you ping another contributor asking for help, please try to do the Bibisect work yourself to track down which commit fixed a bug!

    Once a bug is fixed on all active LibreOffice branches (either by backporting or by branches reaching EOL), or if a developer denies the backport request (by commenting on the report or gerrit), the backportRequest:X.y tag may be removed and replaced with backportDenied:X.y.

    If the fixing commit has been identified, the report can be resolved as "FIXED", or "DUPLICATE" if that commit closes another report that was describing essentially the same issue.


    Used, when Bugzilla is not the proper place for the report.


    The "problem" described by the bug reporter is part of the expected behavior of LibreOffice. Examples:

    • A function works as expected tdf#85643
    • Round-off errors that occur due to floating-point arithmetic on integer values - tdf#86174


    There is a problem here, but it's not a problem in LibreOffice.


    • LibreOffice reads/write the file format correctly, but some other software does not tdf#81854
    • Excel has a longstanding date bug that they can't fix due to backwards-compatibility issues tdf#86996
    • There's a limitation with software outside our control tdf#85652 redmine#845


    As requested in an ESC call, this Status was added to encompass bugs that have been abandoned or don't have enough data for us to proceed with triage and bugfixing.


    • User isn't willing to share a private document with anyone, and we can't reproduce
    • Bug sits in NEEDINFO status for 6+ months


    • We currently mark abandoned bugs as RESOLVED WORKSFORME, or RESOLVED INVALID, but an additional Status value could help us be more precise in indicating why a bug has been set aside.
    • An additional Status would allow us to be more diplomatic with tough users, and avoid the potential negatives of "INVALID" or "WORKS FOR ME" on such bugs


    • A handful of names for this status were proposed:
      • INSUFFICIENT_DATA (Red Hat bugzilla)
      • EXPIRED (Launchpad)
    • The underscore between the two words "INSUFFICIENT_DATA" was removed to match the style of the existing RESOLUTION statuses in Bugzilla