Editor insists on changing Enum-Ref to Ref, when editing App Formula. Smart Defaults bug 👎

[Marc_Dillon]

Just copying this from my support ticket, since it is half feature request and half bug (or at least I consider it a bug).

---------------

Columns have been specifically set as Enum w/ Base-Type as Ref, because I don't need or want the automatic reverse-ref REF_ROWS() VCs in the referenced Table.

Every time I go to edit the App Formula expressions for these columns, the editor insists on changing the column Type to Ref. I have to constantly keep setting them back to what I actually want.

This is just another case where the "smart defaults" are causing more work to have to be done.

1. Please update the smart defaults to know when a change has been manually made, so that it will stop trying to override what I've done. I would consider this a bug.
2. Please add options to turn off smart defaults, as has been asked by many advanced app builders many times over.

---------------

Repro:

1. Have a column set to Enum-Ref.
2. Edit App Formula, to an expression that returns a single key value.
3. Allow the expression assistant to fully verify, then save.
4. Notice the column type changes to Ref.

[SkrOYC]

I can see how this could end as a big dissaster, I'm with you on this one!

Hope this get fixed soon as well as the way to prevent "smart" defaults. I'd love an AppSheet version/option with no defaults at all

[Steve]

Escalated.

[aneeshatgoogle]

Thanks for the reporting this bug. This bug is not due to the smart defaults feature. I have redirected the issue to the engineer who'll take a look today or tomorrow.

I also want to clarify some points regarding the smart default feature:

• Smart default feature is used only by UX Views at the moment.
• Smart default feature does not overwrite manual changes most of the time. It only overwrites when the changes made by the author are fundamental to get the view working for eg. setting view options when author changes view type or table for a view

AppSheet version/option with no defaults at all

---

Defaults are at core of appsheet and have always been there. For example, when you import a table appsheet defaults the columns types and creates default views that make the app work (author can look at them by expanding system views section in UX Views editor). An appsheet version with no  defaults will require author to update too many settings to get the app to work.

[SkrOYC]

@aneeshatgoogle 

An appsheet version with no defaults will require author to update too many settings to get the app to work.

 That's the point

[Marc_Dillon]

Thank you @aneeshatgoogle , hope to see it fixed soon.

I do not know what all "smart defaults" entail, but I just read it literally. I.e. anything the app editor does automatically beyond just leaving it blank or alone.

>>"An appsheet version with no defaults will require author to update too many settings to get the app to work."

I'm sure there's plenty that we're not considering when making such a request, but on the surface, I do not agree with this statement at all. Would it help for us to create a list of annoying "defaults"?

I gave it some quick thought just now, and here is a partial list. I'll try to remember to keep in mind to keep notes on this as I work the next few weeks or so, so as to expand on it.

1. Tables
   1. All columns loaded in as Text.
   2. No automatic Initial Values or App Formulas.
   3. No automatic "_Computed" columns.
   4. No automatic setting of Refs columns based on column names matching Tables (this one in particular is really terrible)
   5. No automatic "Description" settings (only for REF_ROWS I think)
   6. No automatic selection of Required?,PII?,Scan?,etc

[Marc_Dillon]

Not sure when this was supposed to be fixed, but just FYI, as of right now this bug is still present.

[macastan]

@Marc_Dillon apologies for the delay, I'm working on the bug this week. I will update the thread once the fix is out 🙂

[mercmobily]

Is this fixed...?

[macastan]

@cmercy yes this is fixed 🙂

[mercmobily]

Nice one!