reorganizing and renaming (ruthless mode)

Bug #100467 reported by Kit Blake
10
Affects Status Importance Assigned to Milestone
Silva
Fix Released
Low
Guido Wesdorp

Bug Description

Recently I've been playing the editor role (as opposed to
pretending
I'm an author), and the experience is very different. Often
editors
want to make major changes to a site, and Silva is not very
user friendly
for the editors (or the public). As opposed to dealing with
'a' document,
editors are manipulating the site structure, operating on
more of a
global scale.

>> A possible change is to give chief editor and up the
possibility to
>> rename without caring about publication status.

Right.

>> It is however still strange to
>> do this -- if something is open to the public (i.e.
published to some URL),
>> it's not recommended to just rename how one gets there.
If you have to
>> explicitly close this is a good reminder you are doing
something that
>> is going to affect everybody that is accessing your
website, search
>> engines, hyperlinks, etc.

Let's track the steps. The use case is, there are a number of
Silva publications online for the public. Thus they have
published status, and cannot be renamed or moved. The editor
wants to restructure the site a bit.

1. Editor selects a publication(s) and clicks "Rename".
2. Editor proceeds to fill in a new id and title, perhaps for
   multiple items.
3. Editor clicks "Save".
4. System informs editor: "'Name' could not be renamed."
   (Yes, dear... :) This happens all the time.
5. Editor clicks on the Publish tab. The Publish screen
loads, which may
   take a good while. But the editor is a level too high, so
then comes
   a click on the "See icon" in the Version column. The
Publish screen
   loads, which may take....
6. Editor clicks "Select all".
7. Editor clicks "Close public". The Publish screen loads....
   Note that at this point all public documents are now
unreadable,
   and site visitors see "There is no public version". This
is bad.
8. Editor clicks "Select all".
9. Editor clicks "Create new versions". The Publish screen
loads....
10.Editor clicks on the Edit tab uplink to go up and over a
level.
11.Editor selects the publication and clicks "Rename".
   Note that if other publications need to be renamed, steps
5-9 have to
   be repeated for each publication.
12.After moving and renaming, the editor goes to each
Publish screen and
   publishes all. Now the documents are visible for the
public again.

This is a lot of steps.

Since I am a Manager, I don't bother with being reminded. I
punch through
to the ZMI (alt-. ;) and move things around there, renaming
at will.

However, editors don't have this option. They have to do the
multi-step
process. Isn't it strange that they have the rights to make
these
changes, but we force them to go through all these steps?
Shouldn't they just be able to do it?

Revision history for this message
Clemens Robbenhaar (crobbenhaar) wrote :

There is a (rather weak) technical explanation for the
current workflow: so far publishing and closing
content objects could be used as triggers for the
upgoming refrence checks; only these actions currently
change the public site, thus only there actions
may break public references.

 The possibility of renaming public documents would
change this.

 But this is a weak argument, managers can cheat
this via the ZMI, thus it is maybe not relevat; instead
we will need to hack the manage_beforeDelete, etc,
anyway for consistent reference checking ...

Revision history for this message
Flynt (flyntle) wrote :

It is really a lot of steps for editors to change (i.e.
rename in this case) the site structure. I tend to support a
solution, which allows editors to rename a public published)
document without first having to close it.

Anyway, how are the old versions dealt with ? Do the old
versions belong to the new, renamed document or do they
belong to the document with the old name ?

Revision history for this message
Kit Blake (kitblake) wrote :

Allowing name/title changes of published documents will do
nothing with the versions. Thus, if document 'foo' gets
renamed to 'bar', the XML version(s) in the SilvaDoc will
remain unchanged.

Revision history for this message
Martijn Faassen (faassen) wrote :
Download full text (3.1 KiB)

Odd, I thought I posted to this issue at some point.
Somehow that didn't appear here (I mailed it). I dug
it up from my outbox and will paste it in here.

> Let's track the steps. The use case is, there are a number of
> Silva publications online for the public. Thus they have
> published status, and cannot be renamed or moved. The editor
> wants to restructure the site a bit.

Okay, trying to step back and trying to figure out *when* an
editor is in this situation of restructuring a published site.

The web has the principle that urls should remain as stable
as possible. The stability of urls makes hyperlinking
possible at all; if urls changed too rapidly then the web
couldn't work, as intersite links would be broken too
frequently and bookmarks and search engines constantly
out of date.

Silva's system of not allowing changes to published
documents has two positive benefits:

  * it forces the editor to take a conscious action before
actually breaking urls.

  * the editor cannot break stuff by mistake.

The editor can do two things to actually change urls in a
published site. One is the ridiculously long sequence of
steps that you pointed out. The other option is to make a
copy of the subsite to be reorganized. This copy is
automatically closed. The editor can rearrange this, then
swap out the old site for the new site and then publish
everything in the new site.

Perhaps the copying option would be more appealing if that
approach were more obvious/easy, so we should consider ways
to accomplish this.

Another possibility is that the editor simply doesn't care
about stable urls for one reason of another. This could be
because the site is under rapid development; it has to
remain published so people can already use the data that is
there, but it is expected it'll be reorganized quickly as
well. Going through the hypothetical simplified copying step
would be too much complication in this case (would it be?).

[snip]

> Since I am a Manager, I don't bother with being reminded. I
> punch through to the ZMI (alt-. ;) and move things around
there, renaming
> at will.
>
> However, editors don't have this option. They have to do the
> multi-step process. Isn't it strange that they have the
rights to make
> these changes, but we force them to go through all these
steps?
> Shouldn't they just be able to do it?

It should definitely be far easier for them to do it than at
present. Would the copying/republishing solution be
sufficient if it were improved in some way? It would cause a
minimal disruption of the site, as the new copy can be fully
reviewed before it is opened. (though there's
the absolute link question; if those are used then a move &
open in the old place is not that simple).

The other alternative would be for them to just be able to
'do it'. I'd prefer it if there were at least one step they
would need to take to get into this 'unsafe changes' mode.
Perhaps they need to press a button and there's some warning
indication while they're in this mode. That way editors are
still prevented from easily making mistakes ('oops, that was
published and I just deleted it!') normally, but when
they are in 'reorganization mode' they can do as th...

Read more...

Revision history for this message
Martijn Faassen (faassen) wrote :

Tentatively assigning this issue to Guido. The simplest approach would be a flag
stored in the session (that if not available default to 'off' so no session
related breakage) that puts an editor or up into 'Danger mode' (we need a good
name). Parts
of the user interface should become red or something to warn people that they
can easily break stuff. A button on the container contents tab can toggle
this.

When in danger mode, the user can change stuff without being caught by
workflow restrictions; i.e. published documents can be renamed and moved,
as well as folders with published documents in them.

Revision history for this message
Kit Blake (kitblake) wrote :

The other day we called it 'ruthless mode' :)

Revision history for this message
Flynt (flyntle) wrote :

"Twilight Zone", maybe ?

Revision history for this message
Kit Blake (kitblake) wrote :

> Flynt <email address hidden> added the comment:
>
> "Twilight Zone", maybe ?

Then we'll switch the interface colors to the dark and spooky version.

Revision history for this message
Martijn Faassen (faassen) wrote :

Moving this into Silva-0.9.3 land.

Revision history for this message
Martijn Faassen (faassen) wrote :

If ruthless mode does need to be in Silva-0.9.2 please put it back, Kit, with
a note.. It's lots of work though.

Revision history for this message
Kit Blake (kitblake) wrote :

Let's push it forward. It *was* supposed to be in 092, but it's not important
enough to delay the beta.

Revision history for this message
Martijn Faassen (faassen) wrote :

I'm not sure how much nasty hacking enabling this feature for 0.9.3 would
involve. We may need to shift it forward into Silva-0.9.4 land.

Revision history for this message
Sylvain Viollon (thefunny) wrote :

In Silva 3.0b1, an editor and more can renamed copy and move published items without problems. Authors can't.
Rename can be done simply from the listing screen without clicking anywhere else.

Changed in silva:
milestone: none → 3.0
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.