Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Privatize content per user
jakob wrote #309971:
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?
Not that I know, only <txp:php /> is configurable. Could be an option in some future version.
Offline
Re: Privatize content per user
etc wrote #309973:
etc_private_fields v0.1…
Damn, that’s clever.
I wonder if we could formalise something like this in core’s custom fields implementation for 4.8.0?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Offline
Re: Privatize content per user
etc wrote #309973:
Tested very quickly, hence no guaranty applies.
etc, impressive.
Few caveats: With your plug i can allow/disallow users to certain custom field content on a per-article base, no?
That’s nice, if there is very few articles only to be treated and individually treated.
What, if – version #2 – i want to broadly allow certain custom fields to certain users instead? I guess this would require an author-specific admin panel, where i as an author could mark certain custom fields for privacy sensitive content and then allow access to them on a per-author base.
So i would have a list of custom fields, each associated with different authors, for myself, my own needs. If another author would want to treat their privacy settings differently, then they should be able to.
Last edited by jayrope (2018-03-16 18:39:55)
A hole turned upside down is a dome, when there’s also gravity.
Offline
Re: Privatize content per user
@jayrope then I would say create a hidden “template” article, fill the fields you need and duplicate it every time you write a new article. Hope we’ll find something less hacky in 4.8.
Offline
#21 2018-03-16 22:14:48
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Privatize content per user
I’ve got something (adi_minimalism) that might help. In one of those strange Textpattern coincidences I mentioned it here
You set it up via an admin tag on a per user or private basis.
It’s all smoke & mirrors though – I’m simply “displaying none” admin fields.
It’s a bit rough & ready but helped me at the time. Unfortunately can’t differentiate between different glz_custom_fields. Haven’t tested on 4.6 or 4.7 either … caveats, caveats!
Offline
Re: Privatize content per user
gomedia wrote #310041:
I’ve got something … Unfortunately can’t differentiate between different glz_custom_fields. Haven’t tested on 4.6 or 4.7 either … caveats, caveats!
Ai! Unfortunately i use glz_cf on 4.6.2 … Thanx!
Last edited by jayrope (2018-03-16 22:35:44)
A hole turned upside down is a dome, when there’s also gravity.
Offline
Re: Privatize content per user
etc wrote #309987:
The hiding mechanism is elementary, but I’m not sure we can easily formalize all possible criteria.
note: for 4.8.
Is there a release roadmap, also for 4.7? Wrong thread i know, but it’s good news, that it is possible!
If glz_cf gets updated for 4.7, eventually it is more simple to incorporate this into the plugin instead of the core.
If the plugin had two more entry sections in the database,
essentially marking first, if a certain CF is generally private or not, clickable by a tick next to the custom field in the write form,
and then extends to a per-author panel in admin allowing individual authors to provide access to individual other users, then most is accomplished already.
A hole turned upside down is a dome, when there’s also gravity.
Offline
Re: Privatize content per user
etc wrote #310031:
@jayrope then I would say create a hidden “template” article, fill the fields you need and duplicate it every time you write a new article. Hope we’ll find something less hacky in 4.8.
etc, i suppose that wouldn’t work long. It smells like too many double entries for the same content in the database all too soon – here on a multi-user site basically sharing content of partly mutual artist or business or press connections.
Last edited by jayrope (2018-03-16 22:45:18)
A hole turned upside down is a dome, when there’s also gravity.
Offline
Re: Privatize content per user
jayrope wrote #310044:
etc, i suppose that wouldn’t work long. It smells like too many double entries for the same content in the database all too soon – here on a multi-user site basically sharing content of partly mutual artist or business or press connections.
At worst, it’s one mostly empty hidden article per user, that the user will clone (thus inheriting its private fields) with a click and edit when he needs to write a new article. Actually, it’s one hidden article per user group with identical privacy settings.
I agree that’s not ideal, but you’ll need to store these per user settings somewhere anyway. And as a bonus, you can store other shared data (section, category) for free.
Offline
Re: Privatize content per user
jayrope wrote #310043:
note: for 4.8.
Is there a release roadmap, also for 4.7? Wrong thread i know, but it’s good news, that it is possible!
v4.7 is imminent (the beta is out) so I wouldn’t expect new features of that degree for v4.7.
If glz_cf gets updated for 4.7, eventually it is more simple to incorporate this into the plugin instead of the core. If the plugin had two more entry sections in the database, essentially marking first, if a certain CF is generally private or not, clickable by a tick next to the custom field in the write form, and then extends to a per-author panel in admin allowing individual authors to provide access to individual other users, then most is accomplished already.
glz_cf is already updated for 4.7: see here.
But unfortunately what you suggest is not within the scope of it. This isn’t being awkward or stubborn, but there are two good reasons:
- glz_cf uses the current custom field mechanism to add new custom fields which is really just a preference so limited; and it’s own ‘custom_fields’ table for custom fields with multiple values but it is not a row per custom_field to which you could add the necessary extras but a row per multiple-choice value; and textpattern’s language tables for field titles. None of those offer the scope for attaching further custom field metadata such as owner and one-to-many readability states for different other users, so what you’re suggesting would mean adding further tables and input variants adding further layers of complexity.
- glz_cf should be superseded by the core implementation, so I hope it will be made redundant with the next version of textpattern. My aim was to make glz_cf work reliably again and be compatible with existing glz_cfs. Gerhard’s original concept has a fundamental flaw/limitation in the way it stores custom fields that the core implementation will aim to overcome, so I wasn’t planning on making it indispensable in future.
That said, I still think the suggestion I made above to do your own custom_script custom field could be workable if you’re willing to slightly simplify your scope a little to setting certain custom_fields as potentially private for everyone and limiting display according to smd_um user privs level instead of making every custom_field potentially privately viewable for individually named other users, which requires a whole pick and choose interface per field, and that the users update it when new users join.
Regarding etc’s trick of outputting the custom_field via tag, here are two more ideas. The write panel has an option to hook into the save article routine before committing to the database. That you could use to either:
- strip out any txp: tags in the body field so that if other users put a txp:custom_field tag in their article body or excerpt, it would be stripped out before saving.
- to encode your chosen private fields on saving so that even if people could output it, they get only meaningless letter-soup. Only your own page template code (non-public) and your custom_field custom_script (also non-public) should know how to read that back out as normal readable values.
If you want to investigate that further, glz_custom_field hooks into article_save to group multiple choices (such as check boxes) into a string before saving, so you could look at that for pointers, e.g. here and here.
TXP Builders – finely-crafted code, design and txp
Offline