The method given here, is for the server to supply an Access Control Entry (ACE) with each data record. How to do that depends on the application / business, here we just cycle through the different options. Using standard features of jTable with just a little jQuery we use the ACE to determine how jTable responds to user requests. It should be understood that access control, like data validation, must always be implemented on the server, this approach just provides a polite user interface.
By definition the user must have Read access to the record for the server to send it to the user in the first place. Hence all the ACEs have at least Read access, and there is nothing to be implemented in the client.
The Create Access Right does not apply to an existing table row, so again there nothing for us to implement on a row by row basis. If the user cannot Create any records, then don't include the
createAction in the jTable definition. One could use the Create Access Right of an individual record to control the presence or not of the
createAction on child tables.
Below is the standard demonstration jTable code and resultant jTable. The only change so far is to request a different server page, one that will return an ACE with each record, but ignored for the moment. Please try it, to see the normal behaviour.
Now we extend the definition to utilise several standard jTable callbacks and events to implement the access control. We use the jQuery
$.extend function to build on existing definitions, so that we can isolate the new or changing code for simpler discussion.
We overwrite the title for our new table, and add the ACE field. In practice this would be a hidden field, but shown here as this is a demonstration. These demonstration ACE's are very simple, they contain the letters C,R,U & D, the presence of the letter indicates user is authorised to perform that operation.
The first meaningful section is the deleteConfirmation option lines 20 to 26. Inside this callback function, we check the ACE in the data record. If it includes the letter D, we do nothing, the normal delete confirmation dialog appears, and if confirmed by the user, the delete request is sent to the server. However if D is not present in the ACE, then the user is not authorised to delete this record, so the delete request is cancelled and the cancellation message set for jTable to use. jTable does nearly all the work for us.
Controlling UPDATE is just a little more complicated. We use the jTable events formCreated and formClosed to adjust the normal jTable flow. When the formCreated event handler is triggered the HTML form and containing dialog box have been created by jTable. We check the form type and if 'create' we don't need to do anything. If it is 'edit', we check the ACE in the original record for the letter U, and if NOT present then we can change the user experience.
We do three things to make the form read-only.
formDialog.find('#EditDialogSaveButton').hide();may look odd to experienced jQuery developers looking at jTable for the first time. We suspect early versions of jTable shared the dialogs Error, Add & Create/Edit between all jTables on the page, so giving the buttons specific id's was a good thing. However in this demo with jTable version 2.4.0 each jTable has it's own set of dialogs, meaning that there are multiple
#EditDialogSaveButtonon the page. Nevertheless jQuery is smart enough to find the button by id within the dialog.
data.form.find('input, select, textarea').attr('disabled', true);
The last detail is the formClosed event. Here we check the dialog to see if it has a stored original title. If so we reverse the operations in the formCreated handler.
See the results below.
The original question asked how to hide the jTable Update and Delete icons, on a row by row basis. Firstly, that could look pretty messy. Secondly, it would likely generate a lot of support calls, with complaints that buttons were missing. The above approach provides a uniform appearance, and explains to the user why such actions cannot proceed.
A more recent question asked about using record data to control row selection. The next demonstration does that.
Again starting with the standard demonstration, we extend it slightly. Firstly we set a new title, then some jTable options to activate multi-record selection with checkboxes. We also add the ACE field, just to make it visible. The technique works perfectly well without exposing the field to the user.
jTable kindly gives us the recordsLoaded event, which it triggers every time it has downloaded data and constructed a new table. From here on we have to use jQuery to modify the DOM itself, but in a simple way. All we do is loop through each row of the table, recover the associated record, and test if the row is selectable.
In this demo, we are going to misuse the flag C of the ACE to indicate that the record is not selectable. If C is present, we use the
td.jtable-selecting-column selector to find the cell containing the selection checkbox. We give the cell a title attribute, explaining why the row is not selectable. Then we disable the checkbox inside the cell.
Once all the rows have be processed, we turn all the element titles of the jTable into tooltips. The default jQuery styling, makes the tooltip a much more noticeable message than the default browser display of html titles.
If you've made it this far, we hope you've learnt something. We are available to offer local tutoring on a range of technologies, or to build you a website, standard or non-standard. The less standard the better! Contact us at email@example.com