Pls help.... -app has only one table -app has...

Tim_Meske
Participant V

Pls help… -app has only one table -app has 5 slice views associated w the one table Is it possible to only allow user to ‘add’ rows via slice views NOT from the table view?

Seems that when I disable ‘add’ in the table then ‘add’ is disabled from slices also.

0 13 680
  • UX
13 REPLIES 13

Yes … if you disable Add in the source table, you can’t add via a slice.

So enable the Add.

m.j.

Tim_Meske
Participant V

Right but the source table is a view that I don’t want users to ‘add’ from. Only want users to be able to add from a few slice views.

Tim_Meske
Participant V

Thanks!!! So going forward only create slices and slice views.

This way all views are independent? Also, before reconfiguring the current app, what is the best way to backup an app in case these go wrong?

I’m guessing a type of ‘save as’ and simply call it something else?

@Tim_Meske Yes, I recommend using slices instead of tables, and views attached to slices.

@Tim_Meske To create a backup, go to My Apps, open the drop-down menu for the app, and choose Copy. Give the copy a new name. I recommend choosing the option to copy the data of the original app. Once copied, you can test with the copy. Once you’re satisfied, you can back-port your changes to your original app.

Tim … I could be wrong here but you don’t have to have a view for the table.

You just need the table in the data section of the editor.

You can then create a slice based on the table.

Then create a view based on the slice.

No one sees a table view.

m.j.

As @Mary_Jane_Pender suggests, just don’t give the app user a view of the table; only give them views of the slices. If you do this, though, make sure all of your formulas refer to views and not to the table!

Tim_Meske
Participant V

+Steve Coile

Thanks!

New to Appsheet.

Are you able to direct me to a resource/info on how to limit app user from from viewing the table and only giving them slice views.

Tim, just as we said above, basically do not create a view for the table.

@Tim_Meske The app user is presented with the views attached to the Left, Center, Right, and Menu positions available in the view configuration. Left, Center, and Right are the screen-bottom buttons between the Share and Sync buttons. Menu refers to the “hamburger” menu in the upper-left of the screen. So if all of the views you present by these means are attached to slices, you’ve made a good start.

The Ref position for a Table view is used to format the in-line/embedded table of rows that occurs in detail views,commonly to display Ref-type rows (confusingly, Ref has two meanings here, unrelated to one another). The other Ref-position views format those views when the view is needed outside the buttons and menu referenced above.

The big gotcha is with those Ref-position views. The Ref-position view chosen for any particular data is determined by the table or slice containing the row(s) being displayed.

@Tim_Meske Consider a row, [Related Employees By EmpID], of type List, ElementType of Ref, an ElementTypeQualifier that identifies ReferencedTableName: Employee, and an App formula of =REF_ROWS(“Employee”, “EmpID”). This column contains a list of references to employee records. When this column is displayed in a detail view, it’s presented as an embedded/in-line table, typically of the first five rows, and possibly followed by New and View All options.

The format of this embedded/in-line table is determined by the Ref-position view attached to the Employee table: The Employee table because that’s the table the rows are from, as indicated by the ReferencedTableName property in the ElementTypeQualifier

Likewise, if you click on one of the rows in this embedded/in-line table, the Ref-position detail view for the Employee table will be used. If you click to add a New row from this embedded/in-line table, the Ref-position form view for the Employee table will be used.

@Tim_Meske Now, returning to your problem: in the above, Employee is a table, but suppose you don’t want the app user to interact with the table. Instead, you want the user to go through a slice that tailors their experience and/or limits their access. To do so, you must tell AppSheet to reference the slice instead of the table. That means changing the references to the table to the slice instead.

If the name of your slice is Employee_Slice, you would edit the [Related Employees By EmpID] column definition to change the ReferencedTableName property in the ElementTypeQualifier, and the App formula. In both cases, change Employee to Employee_Slice.

This need to reference the slice instead of the table extends throughout your configuration! Every reference to the Employee table must be changed to the Employee_Slice slice. Admittedly, there are places where you could probably get away with referencing the table, but until you’re fully aware of all the complexities, it’s safest to reference the slice always and never the table.

@Tim_Meske “Holy crap, Steve! I reference the table all over my configuration! Changing all those references would be a monumental task! There’s got to be a better way!” There is! It’s actually quite simple: Rename the table, then give the slice the table’s old name! How to:

  1. In AppSheet, in the table’s configuration (Data / Tables), give the table a new name. I add a 0 to the actual table’s name (Employee0), but you could use anything you want (EmployeeTable?). You may but are not required to change the table’s name in your spreadsheet. I don’t recommend changing the name in the spreadsheet.

  2. SAVE the change. THIS WILL BREAK YOUR APP until you complete this procedure!

  3. In AppSheet, create a new slice or rename an existing slice with the newly-renamed table’s old name (Employee) that uses the newly-renamed table. To keep things simple, at least until you become comfortable with the process, configure the new slice to completely reproduce the access the table itself offered.

  4. SAVE the change. This should fix what was broken in step (2).

Done!

Top Labels in this Space