Logged in user's own pages and navigation

edited January 2015 in Modules
Hi

My next Fuel project will involve multiple CMS users and an Admin user. I'd like users to have access to the Pages and Navigation modules but only allow CRUD access to their own pages - and Admin to have access to all. User will be able to create their own pages and associated Navigation but not be able to see or edit other peoples'.

Is that possible with minimal tweaks to the existing Page & Nav modules or will I need to build a new set with the extra features built in?

Any suggestions?

Cheers...

Comments

  • edited 2:27PM
    I've made some updates to the base_module_model in the development branch to allow you to limit the results based on the user that created the page. The changes will only work for pages since they have a last_modified_by field to query on. The fuel_navigation table does not have that field so it would need to be added to your table.

    To implement the updates, download the development branch here:
    https://github.com/daylightstudio/FUEL-CMS/tree/develop

    There is now a property on a model that extends the Base_module_model (which all modules do), called "$limit_to_user_field". You can specify a field to query on automatically that holds the user it belongs to. For pages, this would be "fuel_pages.last_modified_by". To modify the pages model, I'd recommend creating your own model that inherits the fuel/modules/fuel/models/fuel_pages_model.php and is placed in the fuel/application/models/My_fuel_pages.php. In that new model, add the following property:
    public $limit_to_user_field = 'fuel_pages.last_modified_by';
    Then, using the module_overwrites in the fuel/application/config/MY_fuel_modules.php file, add the following
    $config['module_overwrites']['pages']['model_name'] ='My_pages_model'; $config['module_overwrites']['pages']['model_location'] ='app';

    More on module overwrites can be found here:
    http://docs.getfuelcms.com/modules/simple#overwrites
  • Looks intriguing. Thanks for the work. Look forward to having a play... Thanks
  • edited January 2015
    All seems to make sense however I'm having a problem creating a page as a standard user. I've created a new user in Fuel, assigned them read/write permissions to Pages. If I login as that user, pages created by "admin" are hidden, which is great. If I then click to create a new page as that user, I get:

    "Error Number: 1052

    Column 'id' in field list is ambiguous

    SELECT id, location FROM (`fuel_pages`) LEFT JOIN `fuel_users` ON `fuel_users`.`id` = `fuel_pages`.`last_modified_by` WHERE `fuel_users`.`id` = 2 ORDER BY `location` asc

    Filename: /var/www/website/fuel/modules/fuel/core/MY_Model.php

    Line Number: 1136"

    I seem to be able to create pages as "admin" though...
  • edited January 2015
    Setting the "key_field" module parameter in my_pages_model.php (to "fuel_pages.id") seems to fix that but I then get the following when in the list view:


    A PHP Error was encountered
    Severity: Notice
    Message: Undefined index: fuel_pages.id
    Filename: libraries/Data_table.php(937) : runtime-created function
    Line Number: 5


    A PHP Error was encountered
    Severity: Notice
    Message: Undefined index: fuel_pages.id
    Filename: controllers/module.php(447) : runtime-created function
    Line Number: 24

    I think there'll be a set of these for each page in the list.

    Do you think I can ignore them since they're "notices"? This Fuel instance is using my normal PHP Error reporting settings - I've not seen these before...

    BTW. I'm not using the full Git develop branch as the ckeditor configuration settings feature seems to be broken - I've just pulled base_module_model.php across into my v1.2 instance...
  • edited 2:27PM
    I've pushed an update to MY_Model to automatically append the table name if it doesn't exist for the options_list method. Also the CKEditor configuration issue should be fixed now in the develop branch as of this morning.
  • Great thanks. Messages have gone now. And CKEditor's config is loading.

    Does the pages list view have it's own formatting somewhere? I've extended
    class MY_pages_model extends Fuel_pages_model
    and added my own
    function list_items($limit=NULL,$offset=NULL,$col='',$order='asc',$just_count=FALSE) { $this->db->join($this->_tables['fuel_users'], $this->_tables['fuel_users'].'.id = '.$this->_tables['fuel_pages'].'.last_modified_by', 'left'); $this->db->select($this->_tables['fuel_pages'].'.id,location,layout,last_modified,published,'.$this->_tables['fuel_users'].'.user_name AS `owner`',false); $data = parent::list_items($limit,$offset,$col,$order,$just_count); //if (!$just_count) { echo $this->debug_query(); exit;} //if (!$just_count) { echo '<pre>DEBUG::';echo print_r($data,true);echo '</pre>'; exit;} return $data; }
    but the "owner" field doesn't appear in the list view (normally on other modules, I'd use this select to specify what I want to see on a list view). My model is the one that gets called (the debug_query() appears for example when I uncomment it)
  • edited January 2015
    If a super-user (admin) edits another user's page, the "fuel_pages.last_modified_by" field is updated and so admin takes ownership and the page disappears from the user's list.

    I've overridden:
    public function on_before_save($values) { $CI = get_instance(); //$this->_editable_by_user(); $user = $CI->fuel->auth->user_data(); //$values['last_modified_by'] = $user['id']; $values['last_modified_by'] = ($values['last_modified_by'] == '')?$user['id']:$values['last_modified_by']; return $values; }
    Which fixes the problem but it does raise the issue between the purpose and usefulness of "last_modified_by" in this context. Perhaps an additional "owner" field should be used instead?

    BTW: With $this->_editable_by_user(); enabled, the pages fails to save with an error claiming you do not have permissions (there's a PHP error too):
    Severity: Notice
    Message: Undefined index: fuel_pages.last_modified_by
    Filename: models/base_module_model.php
    Line Number: 1062
  • edited 2:27PM
    That's a valid issue. The last_modified_by field shouldn't change if you have it limited to just a single user. So something like the following should work:
    public function on_before_save($values) { $CI = get_instance(); $this->_editable_by_user(); $values['last_modified_by'] = (!empty($this->limit_to_user_field) AND !empty($values['last_modified_by'])) ? $values['last_modified_by'] : $CI->fuel->auth->user_data('id'); return $values; }

    Regarding the error you were seeing, I'm not able to replicate that issue as of yet. Do you have other replication steps.

    Regarding the fields, you can override the fields displayed in the list view with the table_headers module parameter which the pages module does have set (see the fuel/modules/fuel/config/fuel_modules.php file). To alter that, add your own table_headers value as a module overwrite, or set it as an empty array and it will pickup what you have set in your list_items method.
  • I think the base_module_model::_editable_by_user() function is wrong.

    As it stands, and with a small selection of pages owned by two users, it seems to work - but more by accident.

    The resulting query is
    SELECT fuel_pages.*, fuel_users.user_name, fuel_users.first_name, fuel_users.last_name, fuel_users.email, CONCAT(fuel_users.first_name, fuel_users.last_name) AS full_name FROM (`fuel_pages`) LEFT JOIN `fuel_users` ON `fuel_users`.`id` = `fuel_pages`.`last_modified_by` WHERE `fuel_users`.`id` = last_modified_by AND `fuel_users`.`id` = 2 LIMIT 1

    In my news module, the resulting query is
    SELECT `news`.*, `fuel_users`.`user_name` AS owner FROM (`news`) LEFT JOIN `fuel_users` ON `fuel_users`.`id` = `newsOwner` WHERE `fuel_users`.`id` = newsOwner LIMIT 1

    This isn't locating the record that's being edited. Shouldn't the WHERE be looking for this_table->key_field = current_record->key_field->value? eg ("WHERE `news`.`newsID` = 3" (3 being the id of the record)
  • edited January 2015
    There was periodic bug with MY_Model::options_list() method on the develop branch earlier this week, that would have both the keys and values be equal in a dropdown list (which could be used for filtering the data). Is that what you may be experiencing? If so, that issue has been updated in the develop branch.
  • Yes. A new pull from Git seems to have fixed that. Seems stable currently...
Sign In or Register to comment.