Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2018-12-29 23:28:57

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,743
Website

Plugin callbacks / methods for restricting UI to the logged-in user?

I’m in the process of updating an old txp 4.5.7 site that had a number of custom modifications to restrict the admin area to only the logged-in user’s files.

Previously I directly modded /include/txp_article.php, /include/txp_list.php, /include/txp_image.php, /include/txp_file.php to restrict the list pages to show just the own users articles and to restrict the sections that an author could post to. Most of the modifications were fairly simple: adding a WHERE restriction and removing options from UI widgets etc.

I’m now trying to achieve the same for txp 4.7.2 but with a plugin. I’ve made some headway and achieved the following:

  • List views: the article list pages show only the logged-in users own files. Likewise the images and files.
  • Write tab: Section dropdown restricted to user’s own section plus certain allowed sections
  • Write tab: Recent articles only show the author’s own articles
  • Search widget – UI: I’d like to remove/unset certain options such as search by section or author. [resolved: see next post]
  • Multi-edit-form – UI: I’d like to remove/unset certain options such as change author and change section. [resolved: see next post]

However, some problems remain and some UI widgets I’ve not been able to replace/simplify:

  • Search widget – results: searching still finds entries by other authors, i.e. the additional admin_criteria restriction doesn’t seem to be being applied to the search results.
  • Write tab: next-prev article nav buttons should navigate only between the user’s own articles. Failing that, remove the widget entirely.
  • Write tab: prevent the edit pane from even showing articles not by the author or in the permitted section (e.g. by putting the ID in the url manually). I tried a method attached to article_saved and article_posted to at least prevent saving of those articles but have not had results (I’m using the plugin directory so don’t have any plugin flags set at the moment).

Not all these items appear to addressable with pluggable_ui and others just need an addition to the $criteria. I’d appreciate any advice or the addition of pluggable_ui hooks if possible.


TXP Builders – finely-crafted code, design and txp

Offline

#2 2018-12-31 00:10:36

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,743
Website

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

Through trial and error, I solved a few items:

Search methods can be removed from the search UI dropdown, e.g. here from the article list

register_callback('restrict_search_methods', 'search_criteria', 'list');

function restrict_search_methods($event, $step, &$data, &$rs)
{
    // Uncomment to see available options
    // dmp($event,$step,$data);

    // Remove author from the search choices
    unset($data['author']);

}

And to remove items from the multi-edit dropdown (on the articles list)

register_callback('restrict_multi_edit_options', 'list_ui', 'multi_edit_options');

function restrict_multi_edit_options($event, $step, &$data, &$rs)
{
    // Uncomment to see available options
    // dmp($event,$step,$data);

    // Remove change author, change section and change comments from the multi-edit options
    unset($data['changesection']);
    unset($data['changecomments']);
    unset($data['changeauthor']);

}

Use file_ui, image_ui etc. in the register_callback for the other panes and uncomment the dmp line temporarily to discover what options/methods can be removed.

If you wish to restrict the behaviour to a certain privilege level, add the following at the beginning of the function. E.g. to restrict this just to staffwriters:

// Get the logged-in user name
global $txp_user;
$user = doSlash($txp_user);

// Fetch the logged-in user's privilege level
$privs = safe_field('privs', 'txp_users', "name='$user'");

// Exit restrict function if user is not a staff writer
if ($privs != '4') {
	 return;
}

@devs: 2 questions:

  1. why does it need &$data in the function attributes? Without the & it doesn’t work.
  2. And I’ve had no luck with the search results respecting admin_criteria restrictions despite the fact that the search filter does have that callback (see line 204 of /vendors/Textpattern/Search/Filter.php) and the $event_list seeming to be the same as the regular admin_criteria. Does the callback function have to be constructed differently?

TXP Builders – finely-crafted code, design and txp

Offline

#3 2018-12-31 16:41:42

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,468
Website GitHub

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

jakob wrote #315848:

why does it need &$data in the function attributes?

That particular callback is by reference so to alter the value in the calling function you need to use the ampersand. Just a PHP thing.

And I’ve had no luck with the search results respecting admin_criteria restrictions

Hmmm, this appears to be an issue in the filter function. We should really wrap the WHERE clause in brackets so that any additional stuff you might add is put afterwards and affects the whole query.

As it stands, it creates a whole series of OR statements and tacks the AND (your extra query) on the end. This gets short-circuited by MySQL so it doesn’t work properly. It works on the main panel because the query is simple (‘1’) but when the query becomes more complicated, things break.

You could try a patch as follows. Change line 204 of vendors/Textpattern/Search/Filter.php to this:

$out['criteria'] =  '( ' . $out['criteria'] . ' ) ' . callback_event('admin_criteria', $this->event.'_list', 0, $out['criteria']);

No warranties as I don’t know what it’ll do to other queries but if it works under vigorous testing then we could probably change it permanently without ill effect.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#4 2018-12-31 17:26:16

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,743
Website

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

Bloke wrote #315866:

That particular callback is by reference so to alter the value in the calling function you need to use the ampersand. Just a PHP thing.

Thanks! And I recognise that because it’s addressed as callback_event_ref in the code?

You could try a patch as follows. Change line 204 of vendors/Textpattern/Search/Filter.php to this:

$out['criteria'] = '( ' . $out['criteria'] . ' ) ' . callback_event('admin_criteria', $this->event.'_list', 0, $out['criteria']);...

Yes, that does it! Phew, thought I was going crazy. Works very nicely now :-) THANK YOU!

jakob wrote #315834:

Write tab: next-prev article nav buttons should navigate only between the user’s own articles. Failing that, remove the widget entirely.

Any chance of adding a callback for the next/prev buttons (article_nav partial) on the write tab? As far as I can tell, it would need to act on query in the function checkIfNeighbour in /include/txp_article.php.


TXP Builders – finely-crafted code, design and txp

Offline

#5 2018-12-31 21:12:49

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,468
Website GitHub

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

jakob wrote #315867:

And I recognise that because it’s addressed as callback_event_ref in the code?

Yep. Also, I think one of the pluggable_ui() parameters is also passed by reference. I’d have to check though.

Any chance of adding a callback for the next/prev buttons (article_nav partial) on the write tab?

Don’t see why not. What do you think, Oleg? Can we do this in a sensible and usable manner to help people customize the experience in a similar way as we do on the Articles panel with the admin_criteria callback? If so, I propose we use the same callback event name here with a Write-panelish step.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2019-01-03 10:46:43

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,743
Website

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

Apologies for bumping this again so soon, but maybe it went unnoticed (specifically to Oleg) over the xmas break.

my request: Write tab: next-prev article nav buttons should navigate only between the user’s own articles.

and:

me: Any chance of adding a callback for the next/prev buttons (article_nav partial) on the write tab?

Bloke: Don’t see why not. What do you think, Oleg? Can we do this in a sensible and usable manner to help people customize the experience in a similar way as we do on the Articles panel with the admin_criteria callback? If so, I propose we use the same callback event name here with a Write-panelish step.

That would be excellent, along with an indication of how to use it.

Write tab: prevent the edit pane from even showing articles not by the author or in the permitted section (e.g. by putting the ID in the url manually). I tried a method attached to article_saved and article_posted to at least prevent saving of those articles …

It turns out I don’t really need the article_posted / article_saved because there is no save button when staffwriter privs are restricted to edit.own. However, they can still call up other people’s articles, including unpublished stuff.
What I had in my patched txp_article.php file was a “restricted_area” notice when an article was accessed that did not belong to the user. Can I hook that via plugin function into admin_side > main_content and somehow restrict it only to the write panel and the “is user’s own article” condition?


TXP Builders – finely-crafted code, design and txp

Offline

#7 2019-01-03 16:41:55

etc
Developer
Registered: 2010-11-11
Posts: 5,240
Website GitHub

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

Sorry guys, I’m skiing in the Alps this week and avoid coding after the vin chaud. Sure, callbacks should be made more consistent, but probably it would better be done via user privs restrictions rather than admin_criteria. Or both, for more flexibility?

Offline

#8 2019-01-03 22:16:49

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,743
Website

Re: Plugin callbacks / methods for restricting UI to the logged-in user?

Yes, an alternative – if this could be useful to other people – would be to introduce a priv such as list.own that only shows one’s own articles in the list view and search, only pages next/prev between own articles and only allows you to open articles/images/files/links that are one’s own. Perhaps a new user type such as guest to go with it.

But, failing that, a callback would do it so that it can be regulated by a plugin. It would, as you say, be more flexible.

Enjoy your skiing – and vin chaud – and apologies for the interruption :-)


TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB