Privatize content per user

jayrope · 2018-03-15 14:14:13

I am wondering, what is the most elegant way to privatize parts of article content, so that it can only be seen in full by the original author, and additionally by other individual authors, who have been authorized to be able to see my content?

Any hints are appreciated.

Bloke · 2018-03-15 14:25:15

Define “privatize” and we’ll go from there:

Omit some content entirely within the article body, but have it still “there” when saved? (Write panel)
Hide chunks of individual article content from the public site.
Hide articles from the public site in their entirety if not authorized to see them.
Hide articles from the admin-side Articles panel if you’re not one of the approved authors.
…

EDIT: like wot Uli said (better than me) ——vvv

Last edited by Bloke (2018-03-15 14:28:48)

uli · 2018-03-15 14:26:27

Front of site or admin side (or both)? CSS-hidden or non existent in source code? All automatically assigned or with manual intervention?

jayrope · 2018-03-15 14:38:10

Thanx, Stef and Uli.

Say, i have a custom field for private phone numbers, “phone private”.

I want to disallow the viewing of data in this field (also in source code) by other registered users, for instance to protect the owner of the phone number from unwanted calls, so simply to protect this person’s privacy. Only the article author should be able to see the content of this, both in front- and backend.

But author should additionally be allowed to grant viewing access to this custom field to single or multiple other registered authors of the site.

A combination of smd_user_manager and smd_access_keys eventually?

Last edited by jayrope (2018-03-15 14:43:46)

Bloke · 2018-03-15 14:53:50

Thanks for the clarification. smd_access_keys is a sledgehammer for this nut. Too much overhead. smd_user_manager’s <txp:smd_um_has_privs> tag should be able to do everything you want on the public site. Just wrap certain tags in that and use the group="1, 7" (or whatever) attribute to only show the full article content to Publishers (you) or your trusted third parties (in custom group 7). Bonus: you can also restrict other parts of the UI from the plugin’s priv management screen.

Admin side: bit more tricky. You’ll need a (small) custom plugin to hide certain custom fields from the UI in their entirety if current user is not in one of the groups defined above. You can do that with a simple callback hook on the custom fields group and do search/replace to hack out the field you want to hide, then return what’s left.

BUT be warned. Anyone who edits the article when in this mode may irrevocably remove the custom content. So make sure your lower-priv users only have privs to ‘edit own’. I may be wrong here. Removing a custom field from the UI in its entirety may just tell Txp to silently skip it and write content in the fields that are POSTed, but I suspect it won’t do that and will overwrite all fields. Never tried it though. Might be surprised.

EDIT: I really need to get smd_um working properly with the new user and password workflows in 4.6.2+

Last edited by Bloke (2018-03-15 14:55:20)

jakob · 2018-03-15 15:36:03

Bloke wrote #309957:

Admin side: bit more tricky. You’ll need a (small) custom plugin to hide certain custom fields from the UI in their entirety if current user is not in one of the groups defined above. You can do that with a simple callback hook on the custom fields group and do search/replace to hack out the field you want to hide, then return what’s left.

BUT be warned. Anyone who edits the article when in this mode may irrevocably remove the custom content. So make sure your lower-priv users only have privs to ‘edit own’. I may be wrong here. Removing a custom field from the UI in its entirety may just tell Txp to silently skip it and write content in the fields that are POSTed, but I suspect it won’t do that and will overwrite all fields. Never tried it though. Might be surprised.

Thinking aloud here on this admin-side question. Is this something that could be done as a glz custom script custom field? The custom script would ask … in pseudo-code: does this use have the required viewing privs (from smd_um etc.)? If yes, show text field (just a copy of or a call to the regular text input field), if no, place a hidden input field here with the value? Would that not allow the article to be saved as normal without risking overwriting it? The caveat – that’s just come to mind while I am writing – is that I guess the hidden field could still be seen by looking up the page source code, right?

Second thought aloud: if those without the respective viewing privs are also unable to save other people’s articles (edit.own), then perhaps such a custom script custom field can simply skip showing the field and as the page can’t be saved anyway.

Bloke · 2018-03-15 15:59:11

jakob wrote #309959:

If yes, show text field, if no, place a hidden input field here with the value?

Yes, glz_cf could do that. So could any custom plugin. But, as you say, the existence of the hidden field means it’s potentially visible.

If missing fields truly are overwritten (testing required), the way round that is to get the plugin to run a “pre” callback hook on save. That would fetch the current values from the DB for all fields known to be hidden, injects the values into the POST array and then bails out to leave Txp to save the result with the hidden values “in place” in the array.

Second thought aloud: if those without the respective viewing privs are also unable to save other people’s articles (edit.own), then perhaps such a custom script custom field can simply skip showing the field and as the page can’t be saved anyway.

That’s genius :-) Why didn’t I think of that?

etc · 2018-03-15 16:11:48

How all this protects from including

<txp:article_custom id="[restricted article id]">
    <txp:custom_field name="secret_field" />
</txp:article_custom>

in another article?

We should think twice on the custom field properties in 4.8.

Bloke · 2018-03-15 16:22:42

etc wrote #309962:

We should think twice on the custom field properties in 4.8.

^ This.

The custom-fields branch is merged and virtually up-to-date, has things Todo, bugs to fix, corner cases to make more rounded. I’ve had a preliminary discussion with jakob about it. Lots more discussion to be had with as many people as possible to gauge input (not design-by-committee!) so I’ll start a thread about it, probably at the weekend once I’ve had a chance to iron out a few glaring flibbles, and we can go from there.

And in answer to your question, it does nothing to mitigate that problem of someone with access to the Forms/Pages. It can be limited of course by removing access to those panels, but even then you could (in theory) put an article_custom tag inside an article of your own. Will Txp blow up with recursive Form acccess? Should be okay if it’s only 1 article.

I have no idea how we could ever sidestep this. Putting permissions on fields sounds like a minefield but I’m willing to explore anything…

etc · 2018-03-15 16:52:24

Bloke wrote #309963:

The custom-fields branch is merged and virtually up-to-date, has things Todo, bugs to fix, corner cases to make more rounded. I’ve had a preliminary discussion with jakob about it. Lots more discussion to be had with as many people as possible to gauge input (not design-by-committee!) so I’ll start a thread about it, probably at the weekend once I’ve had a chance to iron out a few glaring flibbles, and we can go from there.

4.8 looks excitingly challenging!

And in answer to your question, it does nothing to mitigate that problem of someone with access to the Forms/Pages. It can be limited of course by removing access to those panels, but even then you could (in theory) put an article_custom tag inside an article of your own. Will Txp blow up with recursive Form acccess? Should be okay if it’s only 1 article.

I guess one can put <txp:article_custom /> inside his article, with a bit of notextile. There is no form involved here… and in 4.7 we have pushed the max recursion depth to 15 anyway :-)

I have no idea how we could ever sidestep this. Putting permissions on fields sounds like a minefield but I’m willing to explore anything…

Don’t think we can atm. Custom fields are not designed to be private.

jayrope · 2018-03-15 17:12:20

Bloke wrote #309963:

I have no idea how we could ever sidestep this. Putting permissions on fields sounds like a minefield but I’m willing to explore anything…

Very interesting to follow your discussion. The ideal way i could imagine is, that i can tick a little box next to any CF saying (private) so that CF would gain a special feature private – and then i could allow single or groups of other users to see this content, or not.

The whole point, why i am asking, is, that we are in the process of creating a private, but among members shared database of cultural info here. In other words, people who are members should have the choice to share and what to share with the info they provide from their own cultural management sphere.

Like, if i have the direct contact to Super-Artist-Pim-Pam-Pum, i might still want to keep the private contact info for me, but share the rest of info with other individual or groups of members, who should have the same priviledge to deal with the information they supply to the shared database.

Last edited by jayrope (2018-03-15 17:19:26)

etc · 2018-03-15 17:27:40

A rough idea would be to write an admin-side plugin that registers few extra custom fields only for authorized users put, say, in some “public” custom field. Dunno whether we have enough callbacks for this, needs testing.

Bloke · 2018-03-15 18:00:33

FWIW, 4.8 custom fields have a family that is an arbitrary (freeform) grouping field. Core doesn’t use it, but the implication is that plugins can use this field to slice, dice and filter your CFs any way you like.

For example, a plugin might allow you to assign fields to particular areas of a panel (by using, e.g. body, sort-and-display, RealName, etc) to attach them to the (article) Body and (article) Sort & Display and (user) RealName blocks, respectively. Along with the ordinal (position – when I can get it working) this could define where custom fields appear throughout the UI.

Another plugin might use them to do per-section-fields.

Nothing to stop another plugin using the field to represent ‘private’ fields and doing something different with them, as etc suggests in custom public tags, on the admin side, or both.

Point is, the use of this CF property is at the discretion of the plugin author to use their imagination, so all manner of cool implementations might arise from it. #EverythingIsGoingToBeAlright

jakob · 2018-03-15 19:41:32

etc wrote #309962:

How all this protects from including

<txp:article_custom id="[restricted article id]">...

in another article?

@etc, you are cunning ;-)

Not a general solution for the larger problem, but in this particular situation couldn’t you disallow users to use txp:tags in articles in Admin › Preferences?

etc · 2018-03-15 20:22:50

That’s what I meant. This basic plugin will register two “private” custom fields “Privacy” (custom_9) and “Phone” (custom_10) that will be inaccessible via <txp:custom_field /> on the public side. On the admin side, they will only be visible for the users listed in “Privacy” field (if set), plus the article author.

Important: Custom field 9 name and Custom field 10 name must be empty in Admin/Preferences/Custom fields. Edit the plugin code if you prefer to use other fields/names.

Tested very quickly, hence no guaranty applies.

# Name: etc_private_fields v0.1 
# Type: Admin/AJAX plugin
# 
# Author: 
# URL: 
# Recommended load order: 5

# .....................................................................
# This is a plugin for Textpattern CMS - http://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................

YToxMTp7czo0OiJuYW1lIjtzOjE4OiJldGNfcHJpdmF0ZV9maWVsZHMiO3M6NjoiYXV0aG9y
IjtzOjA6IiI7czoxMDoiYXV0aG9yX3VyaSI7czowOiIiO3M6NzoidmVyc2lvbiI7czozOiIw
LjEiO3M6MTE6ImRlc2NyaXB0aW9uIjtzOjA6IiI7czo0OiJjb2RlIjtzOjQ1MToicmVnaXN0
ZXJfY2FsbGJhY2soJ2V0Y19wcml2YXRlJywnYXJ0aWNsZScsIGZhbHNlLCAxKTsNCg0KZnVu
Y3Rpb24gZXRjX3ByaXZhdGUoJGV2ZW50LCAkc3RlcCkNCnsNCglnbG9iYWwgJHR4cF91c2Vy
Ow0KDQoJaWYgKCRpZCA9IGludHZhbChncHMoJ0lEJykpKSB7DQoJCSRkYXRhID0gc2FmZV9y
b3coJ0F1dGhvcklELCBjdXN0b21fOScsICd0ZXh0cGF0dGVybicsICJJRD0kaWQiKTsNCg0K
CQlpZiAoIWVtcHR5KCRkYXRhWydjdXN0b21fOSddKSAmJiAkdHhwX3VzZXIgIT09ICRkYXRh
WydBdXRob3JJRCddICYmICFpbl9saXN0KCR0eHBfdXNlciwgJGRhdGFbJ2N1c3RvbV85J10p
KSB7DQoJCQlyZXR1cm47DQoJCX0NCgl9DQoNCglnbG9iYWwgJHByZWZzOw0KCSRwcmVmc1sn
Y3VzdG9tXzlfc2V0J10gPSAnUHJpdmFjeSc7DQoJJHByZWZzWydjdXN0b21fMTBfc2V0J10g
PSAnUGhvbmUnOw0KfSI7czo0OiJ0eXBlIjtzOjE6IjQiO3M6NToib3JkZXIiO3M6MToiNSI7
czo1OiJmbGFncyI7czoxOiIwIjtzOjQ6ImhlbHAiO2I6MDtzOjM6Im1kNSI7czozMjoiMDVh
ODk5MDExOTlhOTE5NjE3ZmFhOGRiNTYwYzFmMmQiO30=

Textpattern CMS

Textpattern CMS support forum

#1 2018-03-15 14:14:13