Timed release of pages4 users found helpful
The problem I see here is that advanced permissions are quite a bit harder for less tech-savvy users. Many recent sites that I've done use Composer a lot, which makes releasing news pages very easy. However, the Composer doesn't seem to be able to set permissions on the fly and timed release is out of question. Also, the workflow for advanced permissions is somewhat uncanny, like "create the page first and THEN set it's permissions", which means that the priceless product announcement page could have been public for a moment too early, which is a tangible risk on high traffic sites.
I've noticed that many people mistakenly think the Public Date is for timed release. I do agree that currently it is done the right way and it shouldn't be used for timed releases, as it now allows sites to have listings like "upcoming events", which have their dates in the future.
I'd like to ask opinions from the community that should there be a Release Date attribute for pages? I mean, should it be there by default without creating any custom attributes that are checked in custom templates etc? On many blogging platforms (like Wordpress) the feature is there and is really easy to use.
There are packages like ProNews that have implemented the feature in some way, but I'd like to ask that should it be in Core by default? What do you think?
I would like to see this as a built-in functionality, too. I've been playing around with the built-in (sample content) Blog function... and even I thought that the "Public Date" attribute for a Blog Entry would be when it was published... and was surprised to find out that it DOESN'T do that. So I would think that any non-techie user would be equally confused.
i dont think advanced permmision can do this.
i have playing advanced permmision for a while, is someone has play with this, 'currently view' with date?
i think a lot of people still use basic permission.
Pecked out on an iPhone
Especially if this could be used from within Composer.
Glad to know its on the cards though :)
And maybe it should be even possible to add the functionality for "timed delete" or "timed hide" for when a page is representing a event, after that event it should not be displayed any more? And all that from the composer - this would be great :)
Thanks to the C5 Team!
(well sans the timed deletion)
you can now turn them on thru the dashboard tho.
Aargh, found it... As before, you have to switch page permissions to "Manually," and in View permission specify the access time for Guest. But then it means that in order to set the timed release a user has to 1) have rights to set permissions 2) switch the page permissions from inherited to manual. I totally agree with spinolaconsulting that this is very inconvenient and restrictive:
To quote spinolaconsulting,
"My authors should be able to write a press release or new product announcement tonight and set it to "go live" tomorrow or next week. They shouldn't have to muck around in page permissions to achieve this. Also, setting the page to "Manual" permissions breaks the permissions model by removing the page's permissions inheritance from its parent."
Too bad there is no progress in 5.6 to address this issue.
We would do it by impacting permissions however- as that's what it is. Who can see the page and when.
Enabling advanced permissions often seems a little heavy(hammer to crack a nut, analogy) when all you want to to is provide a way for certain content to be available at a specific time. Advanced permissions adds a lot of extra bits that are (in my case) rarely needed. To be able to do this in composer would be great.
I did once attempt to do something with this and setting attributes depending the post date attribute however this had implications. Pages where not switched back unless someone visits the page, it was not automated correctly. I would be interested to know how the core team work this around the advanced permissions stage? Maybe this is something we could work into a block/package that could circumvent the advanced permissions.
edit *spelling corrections
In my (and other people, as it seems) opinion a "timed/delayed release" feature should have nothing to do with setting permissions at all. I'm afraid it can be in contradiction with C5's idea of timed release as a special case of guest view access though...
copies all the permissions down just as they were, so it's not like
we're asking you to recreate some complicated setup. It seems if
you're depending on inheritance, and you're able to break that because
timed releases exist outside of permissions, your faith in inheritance
should be in question.
I get that "advanced" sounds scary and you might not need all the
power that advanced permissions gives you. That being said, they're
really not that different than the basic permissions. If you don't
start configuring them all strangely, they wont get in your way.
I'm afraid I really don't agree with the idea that controlling who can
see a page and when isn't a permission. Permissions by their very
definition control who can do what, when.
I can certainly see the argument for making it easier to get to timed
releases at the page level, I mean we fell for that argument at the
block level - so that seems like an obvious extension.
I can see the argument for making timed releases work at a basic
permission level. You could still control which group can see it and
when, but not get the opportunity to learn about the rest of the
things you might be able to pull off with advanced permissions.
Where I am on it today is that the potential upside of having a client
start to wonder what else they might be able to pull off with
permissions out weighs the rather measured pain of having to turn on
advanced permissions and show them how it works. Did you know you can
serve different content to different groups? How about making a
private area and turning that small marketing site into an extranet
Much of what has worked for us with concrete5 is clients starting with
an immediate problem and then slowly taking on more and more over time
with their website. My concern is that if we're always rethinking
features to be geared towards one specific immediate use case, and not
taking the opportunity to show people how the tool is solving
problems, there will be no learning, experimentation and creativity.
Ie you're delivering a finished airplane model instead of a lego set.
CEO - concrete5.org
certainly I understand that permissions are copied down when I break the link by setting them to "Manually". But what if later I decide to change root page permissions? They won't be copied down again. That's the problem. Imagine if there are dozens or hundreds of news articles below a root, which all are supposed to inherit permissions of the latter...
Well, hmmm (thinking as I type), maybe in this case the solution is not relying on permission inheritance, but rather using Page Type-referenced permissions?
Another problem. I don't want to give my Content Managers (members of a user group, who are limited in their abilities - they are supposed to manage content, but should not mess around with more sophisticated system aspects) the ability to change page permissions. On the other hand, they should be able to routinely set timed/delayed release. A separate permission like "Schedule Guest Access" would be perfect, but... it works only for Blocks, not for the whole pages.
Lastly, I'm personally not afraid of advanced permissions and feel at home with and very much appreciate the new, complex system of 5.6. At the same time I understand people who don't want to or are not able to dive in this system - but still would like to be able using timed release.
I completely agree with you. We've been implementing CMS applications for years, and the notion that we have expose users to complicated permissions, whilst fundamentally also exposing site-altering behaviour and authoring just to set a publish date/time is crazy.
Whether from a programming perspective it makes sense to have an automated publish start/end date/time in Permissions doesn't mean a fraction of that couldn't be exposed via the user UI to allow, what most end users of the CMS consider, a simple task.
Out clients pay tens of thousands of dollars to design agencies to come up with designs, they pay us to allow their authors to be able to create content and entrust us to make the CMS behave that their authors can't break the design, and so 90% of the time we lock down all the themeing, permissions, layouts, etc for pages and blocks straight off the bat. We want content authors to focus of content, context and publication - not adding 3 column layouts, changing presentation, changing caching rules, etc. Advanced Permissions goes hand-in-hand with this.
From the number of threads talking about this glaring user-centric omission, to the confusing existing Public Date/Time that DOES exist in the Page Properties (which editors then think does achieve part of their timed-publication needs), I think this needs addressing.
For mid-tier clients it's one of the biggest failings of C5 with multi-author deployments (alongside the standard open source propensity to do content editing in a WYSIWYG editor), and is something we have to constantly apologise for to out clients.
I second snobo in everything he has said, and whilst I understand that from a data / model perspective that the exposure of a page with regard role / user / time is a form of permission, the user's view of that and interaction does NOT need to be tied to all of the other advanced permissions that are far more sensitive and potentially damaging to a client's site than simple exposure of, say, a news article or short-time product offer.
Joking aside, thank you very much. Really, I'm most delighted to see the feature coming to basic permissions. Looking forward to 5.7.
"Add Timed Release of Pages #3339"
Timed access can then be controlled against 'Guest' permissions quite easily, see attached.
We even made a setting that will not allow the writer to delete a article fx. 15 minutes after release time.
Either writer or editor needs to be an administrator of the site.
Our package is currently on beta testing on 2 news sits in Denmark...
The package allows you to set the 'Public Date / Time' / 'Date Added' page attribute to a future date / time to control page visibility to guest users. It sets a 'Duration' object against the Guest groups 'view_page' permission which will hide the page from guest users until the given date / time, the same way as advanced permissions works, just a hell of a lot easier for end users.