rah_privileges v0.2 for Textpattern v4.7 (beta)

jakob · 2018-04-01 14:47:12

IMPORTANT: This version is for Textpattern v4.7 only.

See this repo for rah_privileges v0.1.3 for Textpattern v4.6.2.

Configure admin-side user-group permissions from Textpattern’s ‘Admin › Preferences’ panel.

Here’s another Textpattern v4.7 compatibility update to a useful admin-side plugin that’s currently orphaned. rah_privileges has been around for a long time on Jukka’s / gocom’s GitHub account as a so-called toolshed project, but in my experience it has worked reliably and can replace the much older bot_privs entirely.

Jukka began an update to the plugin the last time he resurfaced in March 2017 but didn’t complete it, leaving it displaying unidentifiable privilege names. I tried unsuccessfully to update it in the past but now with knowledge gained from my recent updates of glz_custom_fields and bot_wtc I had a second attempt and it works!

Download

Download here: Plugin files
Source here: github.com/jools-r/rah_privileges

Usage

Open the ‘Admin › Preferences’ panel and switch to ‘Privileges’. Set the checkboxes to permit or disallow access to a particular action or panel for each user group (“publisher”, “designer”, “staff writer”, etc.). This can be an entire panel or a sub-action of a panel (e.g. edit own articles). Privileges introduced by plugins should also be automatically added.

Use with care to avoid locking your users or yourself out of particular parts of the admin area.

Changes in this version

Updated to work with Textpattern v4.7’s ‘preference’ panel.
Fixed: privilege name strings showing incorrectly.
Fixed: User-level language strings not being translated.
Translatable UI text (English, German, Finnish included – see Textpacks).
Revised help text.

Credits

This plugin is almost entirely the work of Jukka / gocom. All I’ve done is fixed the display mechanism for Textpattern 4.7 and some minor styling edits.

Feedback

Feedback, improvements and Textpack additions welcome.

colak · 2018-04-01 15:19:15

Thanks so much for updating this one Julian… It is very handy for our site.

phiw13 · 2018-04-02 08:46:21

This seems to work fine, in a brief and not-really-thorough testing. Nice work.

One minor quibble. Please remove the font-size from #prefs_group_rah_privs .txp-form-field-value span {}. 12px is sooo unreadable. Thank you.

phiw13 · 2018-04-02 13:22:29

Noticed something else:

.txp-tabs-vertical-group .txp-form-field-label, .txp-tabs-vertical-group .txp-form-field-value { flex: 1 1 100%; }

makes a mess of the Preference panel. Now .txp-form-field-label (the label) displays above .txp-form-field-value (the input area), instead of having them side by side to medium to larger screens.

If you absolutely want both fields to be full width of the column on the privileges sub panel, you’ll need to be more specific:

#prefs_group_rah_privs .txp-tabs-vertical-group .txp-form-field-label, #prefs_group_rah_privs  .txp-tabs-vertical-group .txp-form-field-value {}

or more simple. Delete the selector above and use:

#prefs_group_rah_privs .txp-form-field { flex-flow: column }

jakob · 2018-04-03 21:46:47

Thanks Philippe, I like 13px better too but on longer languages like German it quickly begins to wrap. I’ve reverted back to txp standard. I also noticed that I needed to be more specific about just adressing the rah_privs prefs group.

I made a few further modifications. The plugin as it was presupposes that you know what the privs do and looks pretty cryptic to a new user. Also Jukka’s mix of some localised strings (from the in-built langset) and some priv names resulted in a mix of translated and untranslated privs and a strange sort order. So I gave them all a dedicated language string instead and tried to name them consistently so they are grouped together better (see updated screenshot above). The order/grouping is somewhat improved now, although some blocks (such as article, file, image, links) are separate from the menus. I also appended the original privs name for those who want/need to know and Stef gabe me some pointers to those prefs I wasn’t sure about.

I’ve also included some plugin privs I know about and that may come up more often but it’s inevitable that some privilege strings may appear as rah_privs_priv_name in the list when they get added by plugins. If we can collate them and what they do – for example in this thread – I can add those bit by bit to the textpack.

To update, use the new installer (I’ve not bumped the number, so re-download please) and then revisit/refresh the Preferences pane. The first time takes a moment to generate all the strings. ~~If you don’t see the correct names right away just refresh once more.~~ Thereafter they should stick and load promptly.

phiw13 · 2018-04-03 23:27:10

jakob wrote #310595:

Thanks Philippe, I like 13px better too but on longer languages like German it quickly begins to wrap. I’ve reverted back to txp standard. I also noticed that I needed to be more specific about just adressing the rah_privs prefs group.

They would have been wrapping to a second line anyway with my browser window :-), or with my iPad, or for a user who forces a larger minimum font-size in her browser, or… I wouldn’t worry about that at all. You force the checkbox and the label to stay together (span {white-space: nowrap; } ), which is the correct way to handle this.

To update, use the new installer (I’ve not bumped the number, so re-download please) and then revisit/refresh the Preferences pane. The first time takes a moment to generate all the strings. If you don’t see the correct names right away just refresh once more. Thereafter they should stick and load promptly.

Updating went fine (download from here). I had to refresh the Prefs panel to get the labels to display correctly (2x for the 3 languages I tested), but then everything displayed fine.

I’ll try later today to test more thoroughly and logging in as a different user to check if the modified setting apply as expected.

jakob · 2018-04-04 09:52:22

phiw13 wrote #310598:

Updating went fine (download from here). I had to refresh the Prefs panel to get the labels to display correctly (2x for the 3 languages I tested), but then everything displayed fine.

Yes, it’s a minor anomaly that stems from the fact that the language strings have been generated but the fetching of the (old) strings has already happened. One more refresh and it’s no longer an issue. There’s a way of temporarily inserting the freshly generated strings into the currently loaded strings that I had to use in glz_custom_fields where that situation would happen every time you generated or changed the name of a custom field and was much more noticeable. I’ll see if I can add that here too.

jakob · 2018-04-04 16:11:30

jakob wrote #310609:

There’s a way of temporarily inserting the freshly generated strings into the currently loaded strings … I’ll see if I can add that here too.

It wasn’t so hard after all. I’ve added it and updated the repo. A very minor change for a slightly smoother experience.

Textpattern CMS

Textpattern CMS support forum

#1 2018-04-01 14:47:12