Clemens Klein-Robbenhaar wrote:
> Clemens Klein-Robbenhaar <email address hidden> added the comment:
> 
> Another issue: I propose to point the url
> in the generated email to the "/edit/tab_preview" of the object.
> 
> I guess this is the place the editor having to decide about the request
> will look first.
> 
> In case of a rejection the author getting the message will most probably
> want the edit-tab, which is only one click away in this case.
> 
> If no one objects, I will check this in tomorrow.

Agreed, go ahead.

> More issues with request approval via the containers publish tab:
> 
>  - in this case a publication date is required;
>    in the case of a "VersionedContent" publish tab it is not.
>    I guess the latter makes more sense
>    (Actually the publish date cannot really be reused by
>    the Editor deciding about the request).

>    I propose to fix this by not requiring a publish darte field. 

Agreed. Will you do this?

>    One could even omit the publish and expiration date fields for
>    authors; everything they fill in will be lost in the workflow anyway.

I didn't realize things were lost in the workflow. Originally authors
could suggest a publication datetime/expiration time. Possibly this never
worked correctly but the intent was that editors can view this if it's
supplied and modify it if desired.

>    (An alternative is to assume the date is part of the request for
>    approval. In this case the values filled in should be redisplayed as
>    default values if the editor visits the publish tab. This is quite
>    hard to achieve for the containers publish tab.

True. For the container publish tab this can't really work and I imagine
the best user interface is to ignore the author's suggestions.. Possibly
this means the best strategy is to remove the ability for authors to
supply this information altogether... Would simplify the user interface
for authors.. Let's debate this a bit further on this issue. :)

>  - a little annoyance in case of the bulk request:
>    the mail contains a list of messages, where the messages
>    only differ by the URL of the content object.
> 
>    Yes, I see there is code which should ensure there are not send N
>    messages, thus the current state is already an improved one ;-)
>    I just wounder if it would be possible to handle this in a different
>    way. Maybe the original interface I have worked out to the "request
>    for approval" needs to be reworked to request/reject/approve 
>    a lot of content objects with only one message.

You mean the messages should say something like:

Author asked for approval of:

  * foo/bar/baz
  * qux/foo/bar
  * ..

That would indeed be nicer. But rather hard to implement before the release,
I suspect.. Any ideas?

>    The last issue is a non-constructive one, which means I have no idea
>    how to fix this yet. As a corollary I would not complain if this is
>    not getting fixed ;)

It'd just need a rather bigger overhaul of the code..

>  - just another one: if the content is not "published now",
>    maybe one can append the publication date to the generated message.

Sounds good.

>  - any arguments pro or contra filling the "From:" field
>    of the mail with the mail address of the actor (I.e. the 
>    Author requesting approval or the editor rejecting the
>    request/approving the content?
> 
>    I can think of: 
>       Pro: allows simple feedback just by email reply
>       Contra: some people will not like to have programms sending 
>         automatically generated mails with thier "From:" header.
>        
>    The contra argument may be handled by setting the "Reply-To" header
>    instead.

I wouldn't be against this. In general the header issue should be 
reviewed -- right now the emails also have no title, I think.

Regards,

Martijn