[pmwiki-users] Drafts, moderated wikis, and PITS 00755

[Patrick R. Michaud]

Roman wrote:
> When editing the original page:
>    - save page to original location   [Publish]
>    - save page as -Draft              [Save as draft]
>    - save and keep editing            [Publish and edit]
> ...

Based on a comment from IRC #pmwiki, I'm thinking that "Publish and edit"
doesn't make much sense.  If we want to save the edits thus far and
the continue editing, it's much more likely that the edits are draft
edits and not to be published. 

So, I'm currently looking at:

When editing original page:
  - save page to original location      [Publish]
  - save page as draft                  [Save draft]
  - save and keep editing               [Save draft and edit]

When editing -Draft page:
  - save page to original location      [Publish]
  - save page as draft                  [Save draft]
  - save and keep editing               [Save draft and edit]

On Fri, Mar 30, 2007 at 10:32:21PM -0400, Scott Connard wrote:
> A couple of points:
> 
> 1. I also think that Publish is good.
> 
> 2. Save and Edit is ambiguous and needs to be clarified.

See above.

> 3. In PITS 00755, "Pm's proposal ... modified to clarify labels"  
> suggests a single "Save" label with different meanings for an  
> original document vs a draft document.  I think that this is  
> confusing.  I'd also rather always see "Save as Draft" even for  
> untrusted authors.  Another issue to consider is that an entire wiki  
> might NOT have $EnableDrafts turned on [...] using Save for everything  
> doesn't lead them to expect the different behavior.

I completely agree -- so I think the above approach makes it
very clear what is happening.  Authors that are allowed to edit
but not publish pages will not see the "Publish" button (more likely
it will appear but simply be disabled).

> 4. Pm: Are you considering a Publish password so that publishers are  
> given special permissions via a password attr (including id and  
> groups in AuthUser)?

I can see two approaches, both with positives and negatives.  One is
to introduce a "publish" password to pages (which defaults to the
"edit" password when not otherwise set).  This has the advantage of
being consistent, but part of me doesn't like introducing yet another
layer of passwords -- we have quite a bit there already.

Or, we could go the other way and claim that "edit" privileges are needed
to publish, while "draft" privileges only allow creating/editing a draft 
but not publishing.  This seems a bit harder to follow, but it does have
the advantage that 'edit' privileges retain the same meaning ("publish
to original page") even in groups where the draft feature isn't enabled.
Otherwise we have the case where 'edit' passwords mean "able to draft
but not change original" in one group and "able to change original" in
others.

Still another approach would be to delegate the authorization to a central
page that defines "publish permissions"; for example, we can say that "anyone 
who has permission to edit Page.XYZ is allowed to publish".  Then the 
edit passwords of Page.XYZ determine one's ability to publish.  This
has the advantage of not introducing yet another level of passwords to
keep track of... but it isn't consistent with the way we do other
authorization-type-things.

I keep wavering between the approaches, so I would appreciate
hearing feedback on this topic.  What seems clearest to the group?

> 5. Something that hasn't been discussed at all is the history -  
> should the history show what is a Draft vs what is the real document?

Draft edits don't appear in the original page's history -- however, a draft
will have its own page history from the point where the draft was first
started until it is published.  When the draft is published, all of the
changes to the original appear as a single entry in the original's page
history.  

(I'm sure there are people that will want to see the draft's history
duplicated into the original page... but that's a bit more work to handle
and so I'm going with the simpler implementation for now.  If there's
a lot of demand we can add it later (PmWikiPhilosophy #4),  and it's
always possible for an enterprising person to write a recipe that 
implements behavior different from the core default.)

Pm