I would like to use the plugin to allow multiple people to register their delegations for a conference, such that:
I obviously don't want them to see each others' data.
It seems that this would be very easy, but I can't quite crack it. The problems are:
When I set it up, I can edit data from the front end for each user, but when I come into the backend, I cannot see the other users' data.
Is there a way to verifiably export all the data, or to set up a frontend system which shows me, as admin, all the data input by each user in one big table? I expect that is essentially what's happening somewhere in the system.
Thank you for your purchase.
This is quite opposite of what should happen. You should only be able to see your data if you enabled this feature, and see data for everyone from back-end. And that is only if you enable this:
With this option, users can only see and edit their own data when they are logged into WordPress. This, however:
They can add, edit and amend the details for their people from the front end
Is not how it will perform.
What I can offer is a workaround with SQL Query based tables.
Suppose you have a table you wish to apply this feature to, but you need to assign certain user roles for each group of people. My advice would be to download the User Role Editor plugin, and assign a custom role to each group. Then, you can create a table like this:
SELECT new_table.id AS ID,
new_table.role AS Role,
new_table.product AS Product,
new_table.amount AS Amount
FROM wp_wpdatatable_6 AS new_table
JOIN wp_usermeta AS new_table_1
ON new_table_1.user_id = %CURRENT_USER_ID%
AND new_table_1.meta_value LIKE CONCAT('%', new_table.role, '%')
It'd basically pull the user role from wp_usermeta table, but it'd match the user ID so logged in users can only see the data associated to their user role.
I hope that helps.
wpDataTables: FAQ | Facebook | Twitter | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Amelia demo sites | Docs
You can try wpDataTables add-ons before purchase on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables
I understand it a lot better now. I think I see where the issue lies -
Person A is editing their stuff in the front end and they finish
Admin B comes along and makes some small amendment to the data in the back end, but this changes the User_ID integer to 1, and so that row of data becomes the property of the Admin. If the Admin makes no changes, the integer remains the User_ID of Person A. When this happens, the data vanishes for Person A.
Is there, therefore, a way to allow the User_ID to stay with the originator of the data? Otherwise, I think either:
a) the Admin must never make any changes to the data
b) the Admin must be prepared to use MySQL to reassign data if they amend any of it.
Now that I understand the problem, it doesn't necessarily need a fix. But if you know any method to make that work, i would be VERY grateful!
Hi again Ben.
Great troubleshooting - that's exactly what's going on.
Here's what you can do, though. Since that table is editable - it's a server-side table. Which means that you can create a new SQL Query based table which would pull the data from the original table.
1. Table 1 - manual table (for example) where you applied "Users see and edit only own data" - leave that as it is for front-end users. When you go to the "Editing" tab above the table, you'll see its database name:
2. Table 2 - Create a table linked to an existing data source -> SQL table -> Enter query like this:
SELECT * FROM wp_wpdatatable_2
You can use that table for your administrators. When they access this table they will be able to modify it, but since it wouldn't have "Users see and edit only own data" enabled, they would also be able to edit the ID column. My advice is to disable editing for it, to avoid any potential errors. So, when they edit the data in the table, the ID will remain the same as it is in Table 1, and the data they changed will be visible in both tables.
That's actually a very elegant solution to the problem - with the additional impact of teaching me a lot more about MySQL in the process.
VERY happy with this now. Will put a note on to prevent anyone touching the original table, but this seems to be working exactly as I intended it to at this point.
Great news, Ben.
I'm glad I could be of assistance.
If you have any further questions or issues, please feel free to open a new ticket, and we'll gladly help.