New Form Builder Rules - Where is the bug list?

No such official list exists that I am aware of.  This whole thing is embarrassing if you ask me.  I wish we could have resolved all the issues with Pipelines before having to deal with another product upgrade and an even larger list of new bugs.

Here is a list summarizing bugs I've already submitted as a support case:

1. Form Rule names cannot be edited and saved unless you also change some other part of the rule at the same time.
2. Records can be saved even when the "Required" action has been set using a New Form Rule.
3. The "Usage" tab in the Field Properties page shows use of the field in the New Forms that do not actually exist (specifying Form Rule #'s that don't actually use that field).
4. Sometimes existing Form Rules will become corrupted and go to a white screen that you cannot recover from, even when clicking to another page.  Only way to resolve is reload page, and then delete the "problem" form rule and recreate.
5. On the New Forms, inline/embedded reports do not let you hide the button to see "Full Report" or hide the Search Records Widget.  This is not a bug, but a major UI/UX flaw.
   • https://feedback.quickbase.com/app/#/case/301276?currentProductId=3c9d7e83-da43-482e-a58c-14265037ecd0
6. Many cases exist where the user is prompted "Are you sure you want to leave?" a Form Rule, even when no changes have been made
   • https://feedback.quickbase.com/app/#/case/292060?currentProductId=3c9d7e83-da43-482e-a58c-14265037ecd0
7. Certain cases of a Form Rule will not allow the user to perform a conditional statement to test if a field is equal to blank - in particular, this seems to apply to the Related Field key.
8. Within a Form Rule, you cannot "Change Value" of a field to the value in another field unless the field type is exactly the same.  So, multi-select text field cannot be set to the text value of another field because multi-select text does not equal text.
   • Quickbase seems to have addressed this bug.  :)
9. This next one I did not submit as a bug, but a Feedback issue on the Feedback page: you can no longer view a form in the embedded page view using ifv=1 or ifv=0.

Other bugs or issues I have mentioned or discussed openly, but not submitted include:

• Print action is no longer available from New Form.
• Copy Record action is no longer available from New Form.
• Still mobile form limitations.

Unfortunately, there are still more bugs than this.

The product is not usable for my organization until they resolve the most significant bugs.  Such as #2, #4, #7, and #8 on my list.

While I agree it is important to remember the different between a Support Case and Feedback, it's also important to remember the difference between a bug and feedback.  Perhaps in the interest of time, the previous post confuses this a little. 

Feedback insinuates a suggestion to make the product behave differently than it currently behaves.  You should not submit a Bug here simply for the purpose of allowing other users to see it within the Feedback system.  A Feedback example: in the New Forms, I believe some great feedback is that the embedded Report feature should not display the large space-consuming button and search widget by default.  The user should be able to disable it.

Bugs are issues with the software and underlying code or workflows, and should typically be submitted as a Support Case inhibiting the user from using the software platform.  We shouldn't really have to provide Feedback for a bug, as it should be addressed and fixed ASAP by the Product Development team.  For example, some of the Form Rules in the New Form become corrupted with a "white screen of death" that cannot be recovered from, and this make the product essentially unusable of this happens.

The previous post might almost be suggesting that a Support Case is not applicable to all Quickbase Users and Apps, while that couldn't be further from the truth.  The bugs I have submitted through the Manage Cases link are applicable to all users of the New Form product, and were quickly acknowledged.  Just because all other users cannot see my Cases does not mean they aren't applicable to all users - since QB will ideally fix these bugs I submitted for ALL users.  But you can't track the status of bugs I've submitted with the design of this system.

This makes everyones job harder - both at quickbase and for their users.  Ive had many instances over the years where i've put in support cases, got scheduled with quickbase support, talked through it, only to be told its a known issue.  If I could just search through known issues and see that it was already on a bug list and being worked on, neither of us would have wasted our time.