Re: Reject or accept non-draft entries in Wordpress

["Teo Hui Ming" <teohuiming.work@xxxxxxxxx>]

On Jan 26, 2008 7:11 PM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
>
> Teo Hui Ming wrote:
> > On Jan 25, 2008 11:42 PM, Brian Smith <brian@xxxxxxxxxxxxxx> wrote:
> > > The specification doesn't prohibit that behavior. I think
> > it would be better if WordPress also had something in the
> > service document for that user which indicates that they can
> > post only drafts, so that the blogging client can present
> > this information in its user interface. For example, a
> > blogging client like Windows Live Writer that has separate
> > "Publish" and "Save Draft on Server" buttons can disable the
> > "Publish" button.
> >
> > Does it mean the server will need to provide different
> > service documents (probably different URIs) to users with
> > different capability level?
>
> Right, I would give the user his own service document that describes his rights. I would also give each user his own collection feed, that either lists only the entries he can actually edit. Otherwise, the blogging client will let the user waste time editing entries that he/she will not be able to modify.  An alternative would be to add some metadata to each entry, marking whether it is editable or not, but currently there is no standard for this kind of metadata.

In WordPress, a contributor is allowed to create drafts, as well as
view, edit  and remove his own drafts. So, a separate collection feed
listed with his own drafts is a good idea. But then, a contributor can
also view other users' posts, meaning that server should provide
another read-only collection feed listed with all users' posts. But I
believe currently, WordPress only provides one collection feed per
blog listed with all users' posts.

> The server doesn't need to mint a new URI for each individualized service document or feed.

Since server actually needs two separate collection feeds, 1) a list
of editable posts/drafts, 2) a list of read-only posts/drafts from all
users, it makes sense to provide a per-user URI for (1) and a common
URI for (2). But I wonder how other blog applications actually deal
with this issue.

-- 
Teo Hui Ming