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.

Textpattern CMS

Textpattern CMS support forum

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