How do I hide specific Editor row for different users?

pansengtat

I noticed that most Editor code have the same Editor form for across all users of the specific DataTable, i.e. regardless of who goes into the DataTable, they can edit and see the same Editor form (no row hidden from one user to another).

Is there a way to hide a specific row in the Editor form for one user, but unhide for another? How do I do it?

mRender

I have a WHERE clause in my query and only query rows where the user_id is the ID of the person who is logged in.

I set the user_id as a session variable in all of my applications.

allan

Agreed - it sounds like a where() condition would be ideal here: http://editor.datatables.net/docs/Editor-1.3.2/php/class-DataTables.Editor.html#_where

@pansengtat - I don't appear to have either a trial or purchased license of Editor for your account. So I can keep my records up to date, can you confirm if you are using a trial, or a license from someone else's account?

Thanks,
Allan

pansengtat

I think I might have confused some people, lemme rephrase.

What I meant wasn't about hiding a column in the displayed table.
Rather, it's like having the Editor form (the one where users can change the data per entry) with one version of that Editor form different from one user (an admin) to another (a less privileged one).

I did use where() before but from what I gather is that it's for restricting the data for displayed.

Thus, I thought about getting the user's privilege_level and store in a $_SESSION object, and then retrieve it via jQuery so that I can decide what instance of Editor do I wish to use.

eg.) in the JS file, the admin will have instance of Editor with this field:

{
                        label: "Remarks (Admin):",
                        name: "MyRequest.RemarksAdmin"
                    }

Whereas for the non-admin user, this field will be unavailable in their instance of Editor entirely.

Only issue now is that while I can save the data for both admin and non-admin, the non-admin will see the "An error has occurred, please contact the administrator" message. That certainly bugs me, as in the tableEditor PHP file, for both admin and non-admin, the Field::inst(...) sections are the exactly the same, except that the Field::inst(MyRequest.RemarksAdmin) for non-admin is ->set(false)... could it be this causing the issue?

xain819

maybe try this

                    {
                        label: "Remarks (Admin):",
                        name: "MyRequest.RemarksAdmin",
                        type: "hidden"
                    }

allan

Or if you don't want the field at all for non-admin users, modify the code so it is dynamically generated based on access rights.

Allan

pansengtat

xain819:

That definitely helped with the "contact the administrator" error message. Thanks!

allan:

The user requirement I received was that the Remarks (Admin) should be seen in the table for both admin and non-admin users, but not modifiable by non-admin users (i.e. only admin-type users can see this field in Editor). I've done that, so I will show the code here:

function($){
    $(document).ready(function() {
        var curr_rank = document.getElementById('theirRights').value;
        //---Admin---//
        if (curr_rank <= jsRank_rankAdmin)
        {
            editor = new $.fn.dataTable.Editor({
                ajax: "php/recordsEditor.php",
                table: "#pullrecords",
                fields: [{
                                            label: "Remarks (Admin):",
    name: "MyRequest.RemarksAdmin"
}
],
                i18n: {
                    edit: {
                        title:  "Editor Menu (admin)"
                    }
                }
            } );
});
else if (curr_rank > jsRank_rankAdmin)
        {
            editor = new $.fn.dataTable.Editor({
                ajax: "php/recordsEditor.php",
                table: "#pullrecords",
                fields: [{
                        
                        label: "Remarks (Admin):",
                        name: "MyRequest.RemarksAdmin",
                        type: "hidden"
                    }
                ],
                i18n: {
                    edit: {
                        title:  "Editor Menu (non-admin)"
                    }
                }
            } );

Just a follow-up, how do I improve the speed of data processing?

Reason I asked is that I was asked to include a function which will send an email automatically after the user clicks Update in the Editor menu, so I'd thought of using a PreSubmit event for the Editor instance.
I am not sure if a re-factor of the following would increase speed:

editor.on('preSubmit', function(e,obj,action){
                var rmks            = obj.data.MyRequest.RemarksAdmin;
                $.ajax({
                    type: "POST",
                    url: "php/recordsEditor_procEmail.php",
                    data: {
                            rmks: rmks
                            },
                    async: false,
                    success: function(e){
// Some data-passing function here
                    }
                });
            });

xain819

have you tried this
Deferred rendering for speed
http://datatables.net/examples/ajax/defer_render.html

hope it helps

allan

async: false,

Why do you need this? It will lock the UI up and make it look slow?

However, your preSubmit event won't make things any slower in DataTables. For DataTables speed, use deferred rendering as @xain819 suggests.

Allan

pansengtat

allan:

In my PreSubmit, I commented-out "async: false," and tested to see if the speed of calling "recordsEditor_procEmail.php" and then saving the data to the DB is increased. In Google Chrome, it detected that it took 14.61s.

xain819:

I have also used "deferRender": true, on the Editor instance, that only changed the speed of the table loading instead of the Editor PreSubmit event.

I am using PHPMailer inside the "procEmail.php" file, and inside that file I am retrieving each field (both hidden and visible) in the Editor form (JS file) via $_POST["editorField"]. (Reason for this is so that I can print all of these values into the email itself.) I store my email settings in a separate PHP file which this "procEmail.php" file would call.

At the same time, I am retrieving the email address of each recipient through an external PHP file using my own written function. Not sure if that in itself affects the speed. My code is as follows:

function getEmail($ID)
    {
        global $mysql_host, $mysql_port, $mysql_DB, $mysql_user, $mysql_password;
        try{
            $connection = new PDO("mysql:host=$mysql_host;port=$mysql_port;dbname=$mysql_DB", $mysql_user, $mysql_password);
            $connection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        catch (PDOException $err){
            echo 'Connection failed: ' . $err->getMessage();
        }
        
        $sqlStatement = "SELECT Email FROM EmailTable WHERE ID = '".$ID."'";
        $getData = $connection->prepare($sqlStatement);
        $getData->execute();
        $email = $getData->fetchColumn();
        
        if ($email != FALSE){
            return $email;
        }else{
            return NULL;
        }
    }

allan

In Google Chrome, it detected that it took 14.61s.

It took 14.61 seconds to just submit and respond to an Ajax request?!

Allan

pansengtat

@allan

I suspect that the preSubmit event is taking too much time to perform the PHPMailer code, so I am thinking of changing the preSubmit event to submitComplete event instead. How do I pass the values into submitComplete event?

(My trial expired quite recently. Reason to being able to use Editor on current project is because my manager has an account, but I don't have access to that account.)

allan

The preSubmit event shouldn't take any longer to fire than any other event - it is literally just a function call in a loop (as are all of them).

However, doing the mail action on submitComplete sounds like a good idea anyway. There should be no difference to pass values into submitComplete. It will just be triggered at a different time.

Allan