Unfortunately, I was unable to repeat this error.
We have a test application with the Table / Grid “Tabulator” plugin installed.
I sent you a private message with the address of the editor of this application. So full access is open.
Please connect the table in our test application the way it is connected for you, so that we can understand why you are getting the error.
Also, what do you mean by “editable entries”? The plugin allows you to edit entries and this can be seen on the demo pages.
Very nice and functional plugin.
I have a question about data editing.
there is an administrator who has the right and ability to edit data,
there are ordinary users who can only view data through the table and cannot edit them.
And if a regular user is viewing the data (table), and the administrator at this time makes changes to the data.
When will the user see these changes? Will it see the changes after reloading the page, or will the data be refreshed automatically without reloading the page?
Any changes to the database will automatically be visible in the table. Changes can be made not only by the administrator, but also by other users if you give them this opportunity. You can change existing data, delete or add new ones through the context menu of the table.
As soon as there are any changes in the database, they will instantly appear in your table. And no page reload required. You can control this feature using the “trackDatabaseChanges” parameter.
If you still have questions, please contact us and we will be happy to answer you.
Reacts instantly to data changes in the database. The data in the table changes as soon as there are changes in the database.
I really liked the ability to connect an unlimited number of columns and the ability to customize each column individually. And the persistence function that saves the individual settings of each user.
We often have to use tables in our work. I think this is exactly what we need.
Thank you for the great plugin. While building the table in the hidden group during page load, I noticed that the order of columns varies from one page reload to another. When executing the same workflow on a visible group, the order of columns is always predictable. OK in my case as I simply moved the workflow and the table is small, but if anybody wants to save a few seconds by populating in the background they might need to be aware.
Glad that you liked our plugin.
Regarding reordering of columns, we will check and find a solution to this problem.
We will try to resolve this in the near future in the next update.
Update version 1.1.0.
Added the ability to forcibly set the ordinal numbers of columns. + not big improvements.
It is usually not necessary to number the columns. The columns in the table will be in the order in which they are placed in the workflow.
But sometimes (for example, when the table is loaded in a hidden group), the order of the columns may be out of order.
Thanks to 2e0lse for pointing out this bug.
And in this case, you need to force the column numbers in the “index_number” fields of each column.
! ATTENTION ! IN THIS CASE, THE “index_number” FIELDS MUST BE FILLED IN ALL COLUMNS WITHOUT EXCEPTIONS. EITHER ALL “index_number” FIELDS MUST BE FILLED OR THEY MUST ALL BE EMPTY
@MindForApps awesome plugin! I just started playing around with it and have a few questions.
1 - Do I understand correctly that the only way to load data into the table is by using workflow actions? Unlike a repeating group you cant just connect a data source and populate the table. Instead, you must also use a workflow to display the columns you want, correct?
2 - Is there any way to allow users to show/hide columns?
I am very glad that you liked our plugin.
Yes, it is necessary to use a workflow.
As you can see, each column has a very wide range of settings. When creating this plugin, we wanted each column to be configurable separately. And it turned out to be done only through the workflow.
Until now, the function to hide / show columns dynamically was not in demand.
As we understood - you need it.
Today we have added this feature. You can update the plugin (in 1.2.0)
Added the ability to add headerMenu to each column. You can see this on the demo pages.
By default, headerMenu is added to columns of type rownum_col, but you can add this menu to other columns as well.
There is only one nuance, through this menu it will be possible to hide any columns except for columns of the rownum_col type. So if you do not have columns of type rownum_col in your table, then the user can hide all the columns and then will not be able to show them again (Since the headerMenu is in the header of the column, and there are no visible columns). Therefore, we have excluded columns of type rownum_col from the list of hidden columns and the user will be able to hide any column except for columns of this type. Maybe I didn’t quite clearly describe it, but you will understand when you start using it.
@MindForApps Thank you so much for your quick response and action!
I haven’t had a chance to play around with this yet but I think I understand your explanation. To prevent the possibility of all columns being hidden, would it be simple enough to add an option to each column to exclude it from the headerMenu list?
Also, this isn’t a must have but I think it would be nice to be able to show/hide columns via conditions and actions. Other than using this for different user roles, we could also build our own filtering menu to show/hide multiple columns at once. For example, let’s say I have a table with a list of users and each row displays the address of the user. Imagine that the address is not one field but rather consists of numerous text fields (street, city, state, zip, country). If the end user wants to hide the address from the table they’d have to deselect 5 fields rather than just one.
By the way, is this new feature included in the “columns” persistence option?
Added the ability to dynamically hide / show columns.
You can run this action through a workflow.
Added simple show and hide actions, and show / hide toggle switch (maybe it will be more convenient for someone)
Those. the title that you specified in the column settings in the Title field.
Simple show and hide actions will show or hide the column, and the toggle switch will alternate between hiding and showing the column. (If initially the column is shown, then this action will hide it, and vice versa, if the column is visible, then it will be hidden)
You can set whether the column will be shown or hidden during loading in the column settings.
Also redesigned headerMenu. Now you can choose which columns will be displayed in the headerMenu. And you yourself will be able to choose which columns will not be displayed in the headerMenu and therefore cannot be hidden. Before that, only columns of type rownum_col could not be hidden, but now you make the choice yourself.
Yes it will all work with the “columns” persistence option. And persistence mode takes precedence.
1.you have “columns” persistence mode enabled
2.in the column settings, you specified not to show the column on load
3.but gave the user the opportunity to enable the display of this column (for example, with a button)
The user turns on the display of this column and then closes (leaves) the page Then the next time you visit this page, persistence mode after loading will show the configuration that was before closing this page, and point 2 will be ignored.