I am creating a module whose purpose is to display some data. I have a input form that saves data to database; that data is then displayed to the user.

I have created a page where that data can be viewed, edited, and deleted.


My problem is that every user can see this. The best thing I have done is using the global $user variable, and verify that the currently logged-in user is the user who created the data being viewed. Every user could see the Edit and Delete tabs, even when no data was created.

I am trying to figure out how I use the permissions in the same way they are used with the content types, where users can edit any node of a content type, or can edit their own nodes of that content type.

How could I resolve this issue?


If you want to do what done for the Article content type (and any content type), then the access callback for the Edit and the Delete tab should be similar to the following one. I assume the access callback is declared as follow:

// mymodule/data/%mymodule_data/edit
'access callback' => 'mymodule_data_access',
'access arguments' => array('edit', 1),

// mymodule/data/%mymodule_data/delete
'access callback' => 'mymodule_data_access',
'access arguments' => array('delete', 1),

If that is the case, then I would use the following code.

function mymodule_data_access($op, $data) {
  global $user;

  // The data saved in the database need to contain the user ID of the
  // user who created the data, which in this case is $data->uid.
  if ($user->uid == $data->uid) {
    // The currently logged-in user has created the data.
    return user_access("$op own data", $user);

  return user_access("$op any data", $user);

This code requires also the following function to be defined, for paths like mymodule/data/%mymodule_data/edit to be used.

function mymodule_data_load($data_id) {
  // Load the data with the ID passed as argument from the database.
  // Return it, or FALSE when no data is found matching that ID.

The module then needs to define its own permissions.

function mymodule_permission() {
  return array(
    'edit own data' => array(
      'title' => t('Edit own data'),
    'edit any data' => array(
      'title' => t('Edit any data'),
    'delete own data' => array(
      'title' => t('Delete own data'),
    'delete any data' => array(
      'title' => t('Delete any data'),

As for mymodule/data/%mymodule_data/view, I assume you want any user to see the data created by other users; in this case, I would use the following access callback, in hook_menu().

'access callback' => 'user_access',
'access arguments' => array('access content'),

If you want to use your own permission, replace 'access content' with your own permission, which should then be added to the permissions exposed by hook_permission().

Every user could see the Edit and Delete tabs, even when no data was created.

The page to create data should be different from the page showing the data to create. Taking as example the Article content type, the page to create a node of that content type is shown at node/add/article, while the page to see a node is at node/%node/view.

I assumed that every user can create the data more than once; if every user can create the data just once, then the code can be simplified. The code I shown is the most generic possible.

| improve this answer | |
  • Hi, thanks for the explanation. Ill try your's . I have been playing with "node access example" that is in "example's for developer's" module. Whit the private column in table. But your's seems like a more elegant solution. – Mike L. Aug 26 '13 at 15:55
  • I am searching other solutions besides yours. Can it be done using hook_menu_alter , where you call a function that checks if the global $user is the same as the one that created the input. When a user creates a new input his UID is saved to the table as well. – Mike L. Aug 27 '13 at 19:53
  • hook_menu() and hook_menu_alter() are not always invoked, and your code would work in specific cases, for example after a new module is installed, or a module is disabled/enabled. That is why the access is checked by an access callback. – kiamlaluno Aug 27 '13 at 21:37

You should implement hook_permission.
Then you will be able to add custom permissions to view, edit and delete for your custom form.

Nice tip I'm using myself with Drupal is to open the code of one of Drupal's core/contrib modules that implements the same thing you need and learn how it was implemented there.

| improve this answer | |
  • hook_permission() alone doesn't help, if the OP wants to use the "edit own data" and "edit any data" permissions. Also, hook_permission() just declares the permissions implemented by the module, but those permissions still need to be used. – kiamlaluno Aug 26 '13 at 0:54
  • Ofcourse he needs to implement hook_menu and such. Google hook_permission will reveal the full process – rreiss Aug 26 '13 at 6:04
  • Still, since the OP is not asking which hook should be using, and it is evident the OP is missing something else, an answer just pointing out what hook should be used is not much helpful. As I said, hook_permission() is just a minimal part. – kiamlaluno Aug 26 '13 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.