Hey there, Awesome Customers!

Just a heads up: We'll be taking a breather to celebrate International Workers' Day (May 1st and 2nd - Wednesday and Thursday) and Orthodox Easter from Good Friday (May 3rd) through Easter Monday (May 6th). So, from May 1st to May 6th, our team will be off enjoying some well-deserved downtime.

During this time, our customer support will be running on a smaller crew, but don't worry! We'll still be around to help with any urgent matters, though it might take us a bit longer than usual to get back to you.

We'll be back in action at full throttle on May 7th (Tuesday), ready to tackle your questions and requests with gusto!

In the meantime, you can explore our documentation for Amelia and wpDataTables. You'll find loads of helpful resources, including articles and handy video tutorials on YouTube (Amelia's YouTube Channel and wpDataTables' YouTube Channel). These gems might just have the answers you're looking for while we're kicking back.

Thanks a bunch for your understanding and support!

Catch you on the flip side!

Warm regards,

TMS

Okay
  Public Ticket #3630359
Use of a placehoder to track editing/creation of information
Open

Comments

  • Jose started the conversation

    Hi, 

    I have a WPdata-Table that came from a MySQL database. Everything runs smoothly and fine, until I decided to track the user that is making the duplication/creation of a single row.

    I need to have this information in the background, so I created the column called "id_creator" in my database. The purpose of the column is to store who (%CURRENT_USER_ID% or Hidden (dynamic) value) is creating/duplicating the row, not being relevant who is modifying. It is important that the user does not realized that this data is recorded, so the column should be invisible and uneditable.  The reason why this column should be invisible, is that the user cannot see that is being tracked and the reason why should be no editable, is that I need that user cannot modified the value in the interface (in-line or in-pop-up).

    Unfortunately, when it is configured the column as "not editable" or "editable" and move up and down the editing configuration [Editing->Editor input type->Hidden (dynamic)->Current User ID]... This is not working!!!..  the database is created with "0" in the "id_creator" column not saving the current user id.

    I believe this feature is a relevant feature that by working will allow to track information of the interaction with the database data.

  •  1,692
    Miloš replied

    Hi Jose,

    I am sorry to disappoint you, but at the moment we do not have an 'out of the box' solution for SQL Query based Tables.


    Right now, we have a solution only for Manual tables.

    So, if you can somehow switch to using a Manual table created by our Plugin,


    Since wpDataTables version 6.1, we have new standard columns for manual tables (wdt_created_by, wdt_created_at, wdt_last_edited_by and wdt_last_edited_at).

    These columns are automatically created in any new Manual Table, and they are hidden by default.

    They can also not be edited, so front-end users can not know you have these and they can not edit them, unless if you make them visible from the back-end "Column List".

    1455037576.png

    They are doing exactly the function as they are named, so, for example :

    - the 'wdt_created_by' stores the information who is the user who created a new row (by username).

    - 'wdt_created_at' stores the Date and Time when it was created.

    - 'wdt_last_edited_by' will store and keep updating the information which is the last user (username) who edited each row

    - and 'wdt_last_edited_at' stores the date and time when the last edit was made.


    So, for the information who created some row, you can just use the 'wdt_created_by' column information.


    2. We also have these new "Hidden(dynamic) Columns" which are also exclusive only for Manual Tables.

    Please check more on them here.


    3. For SQL Query based Tables, you can only try with custom workarounds.

    You will only be able to store the information who creates a new row, but we don't have a solution for SQL Query Tables to 'update' if another user edits this row - it will just save who created it.


    But I am not sure what you did here exactly, because you mention that you tried to disable the 'editor input type' for your Column which was supposed to store the 'current user iD placeholder' for editing.


    So, the easiest way will be if you can simply use a Manual Table for this purpose;

    For example, you can have one main/master Manual table which will store all the data in the database.

    Then, you can check this table's MySQL Table name from the Editing tab in the back-end table settings,

    and you will be able to make multiple SQL tables that pulls data from the same "master table",

    and any editing you do on all these other SQL tables are going to be stored in the same table in the database,

    This will be my example table :

    3791094982.png

    Now, to make a new SQL Table from it,

    first, check in Editing Tab/MySQL table name for editing:

    6795720227.png

    in my example, the Manual table name is wp_wpdatatable_39,

    so i make a new SQL table that will pull data from it;

    and we can choose all columns like :

    SELECT * FROM Table_Name

    or just specific columns;

    we can also have completely different settings/filtering/sorting and limitations for front-end users on each table;

    and you can make multiple SQL Query tables that pull the same data from the "main table".

    SELECT  column_name1,
            column_name2,
            column_name3
    FROM table_name

    -

    In this example, if i want to limit to only show the "Company" column, and i will leave wdt_ID ( because we got to have row ID)  and userid ( if we want userID for limiting rows per currently logged user ID),

    when i hide those columns in the end, the front-end user will only see the "company" column.

    SELECT  wdt_ID,    
        userid,       
    company     
      FROM wp_wpdatatable_39
    4596672496.png

    Later, you can make another SQL Table that will show some other columns, have other filters and so on ( depending on what you need to achieve)...

    You can see my Video example here https://watch.screencastify.com/v/jOXrsJ9jaspWG5m3VqZH


    Let me know if the workaround for having one "Main Manual Table" which shows everything to Admins;

    and the additional SQL Query with the 'hidden columns' can work for your use-case.

    Thank you.



    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables