If you give users access to the workflow tab (which is what we needed in our situation), I've noticed that users can't access a node they created if they mark it as unpublished. Is this a defect, or is there a hidden purpose behind this functionality? Or am I just oblivious on how to actually access these nodes?

The way I see it, a user might be working on a node, but wouldn't want to publish if its still in draft mode. Then they would revisit it, revise it, and then choose to publish it.

Comments

catch’s picture

Status: Active » Postponed (maintainer needs more info)

"access to the workflow tab" There is no such tab in core. Is this a contrib module?

Do they have "administer nodes" permission?

Also you can get moderation modules (modr8, for example) which allow for 'draft' state whilst still being viewable by non-administrative users.

jgoldberg’s picture

Component: blog.module » node system
Status: Postponed (maintainer needs more info) » Active

There is a workflow tab in core; it displays towards the bottom when you are editing/creating a node. It only comes up only with the "administer nodes" permission. I actually already have a ticket pending regarding that*: http://drupal.org/node/214190

You shouldn't need a contributed module. What is the point of un-publishing a node then (vs. deleting it)? I went on IRC and no one could seem to be able to explain the logic behind why a node isn't accessible to its author if it is unpublished. It seems like being able to keep a "draft" version around that only the author can see is a basic functionality that belongs in the core.

* In our situation, we want our users to be able to manage the workflow of their own nodes, but giving them "administer nodes" means they can also edit each others' nodes. My ticket (pending 7-x) proposes an independent permission just for workflow access.

jgoldberg’s picture

BTW, I should clarify: workflow = "Publish options"

catch’s picture

Status: Active » Postponed (maintainer needs more info)

I can't reproduce this.

Create a node as user/1, unpublish it.

Create a test user, give authenticated users the "administer nodes" permission.

Browse directly to the node as that the test user - node/1 for example - I can see it and edit it as my test user.
I can also access it via admin/content/node

I can also create a node as my test user, set it to unpublished before submit, and I see it fine, can still edit etc.

They don't show up on the front page listing etc., but that's "by design'.

Can you post exact steps to reproduce?

http://drupal.org/node/214190 looks good by the way, see you over there.

jgoldberg’s picture

Title: User can't access unpublished nodes » Does an unpublished status mean Draft or Disabled?
Version: 6.x-dev » 7.x-dev
Category: bug » feature
Status: Postponed (maintainer needs more info) » Active

Interesting, I didn't realize you could pull it up by explicitly referencing it in the browser.

I should refine what I think is the problem. Yes, a user can navigate to that node by explicitly visiting node/. However, from a common user's standpoint, that node is orphaned because there is no way to actually browse to it. My steps to reproduce would be:

* Give user/1 "administer nodes" permission.
* Create a node and in the process uncheck Published.
* (With or without "administer nodes" permission) If user/1 goes to My Recent Posts (tracker/1), the post should not be visible.

Expected behavior: Some way to get to the post without 1) explicitly referencing it in the URL, 2) a module adding said functionality.

There are a number of directions we can take this. My user's intuition was that "unpublished" means its a draft, and he/she can come back to it, work on it, and publish it later. The way it functions, however, is more closely aligned with enabled vs. disabled (even the field in the database is labeled "status"). So either we should treat unpublished as meaning draft mode, or we should change the language to enabled vs. disabled.

It seems like this is turning more into a feature request rather than a defect, so I'm bumping it to 7.x.

catch’s picture

admin/content/node will get them to it - that's the route.

jgoldberg’s picture

admin/content/node will get them to it - that's the route.

Well, for an admin. I'm talking about a regular authenticated user.

catch’s picture

If they have administer nodes permission, they can access that url.

jgoldberg’s picture

Yes, but in an earlier post I pointed out that we let our users manage their own publishing without giving them admin privileges (See: http://drupal.org/node/220825#comment-728290).

catch’s picture

In which case you can override the way things appear in lists with views, or use something like modr8. But this is 7.x issue now, and I agree that a core solution would be best so will stop arguing with you :)

marcingy’s picture

Version: 7.x-dev » 8.x-dev

Bumping version

lpalgarvio’s picture

jstoller’s picture

Status: Active » Closed (works as designed)

Currently Drupal only supports a very basic two-state workflow. Content can either be published, or not-published. Using custom views and such, the not-published state can be made to work like a draft state, or an archived state, but really it just means "don't let non-admins see this". Everything else is up to the site builder to configure.

The patch committed in #218755: Support revisions in different states will make it easier to create drafts in D8, since you can now save a forward revision, without unpublishing your current revision. However, accessing completely unpublished nodes will still require a custom view.

I'm closing this issue, since the system works as intended. If you want support for a true draft state, then I highly recommend supporting the effort at #1777388: Support arbitrary workflow states. The goal of that issue is to add core support for multi-state workflows.

lpalgarvio’s picture