Edgewall Software
Modify

Opened 10 years ago

Closed 10 years ago

#566 closed enhancement (duplicate)

Changesets for Wiki pages (Prepare wiki-changesets)

Reported by: anonymous Owned by: jonas
Priority: low Milestone:
Component: wiki system Version: 0.7.1
Severity: normal Keywords:
Cc:
Release Notes:
API Changes:

Description

It often happens that I want to modify several wiki pages alltogether. These changes belong logically to another. Eg. if you add a new page and add a new link to this page this should be one commit not two.

Therefore I propose the following scheme:

  • A new button/drop-down-box combi [Add to changeset][ … ]
  • If no changeset has already been created by the user currently logged in [Add to changeset][ <create new> ] a new one will be created, else the user can select one to add it to [Add to changeset] [<Add Help x options>]
  • The created changeset is in state pending as long as the user selects

[Commit changeset][…]

Additional benefit: Before a page is initially posted, you can modify it serveral times until it is complete ⇒ You do not spam the timeline (this is what happens for us here)

Implications: Here too we need a consistency check, but for every page that is changed. All conflicts should be displayed and the user should be able to solve the conflicts one after another as it is currently possible.

Attachments (0)

Change History (5)

comment:1 Changed 10 years ago by anonymous

  • Component changed from general to wiki
  • Severity changed from normal to enhancement

marking enhancement+wiki compoentn

comment:2 Changed 10 years ago by jonas

  • Milestone changed from 0.8 to 0.9
  • Priority changed from normal to low

This looks complicated and messy, not sure how this would be implemented, moving into the future…

comment:3 Changed 10 years ago by cmlenz

  • Milestone 0.9 deleted

comment:4 Changed 10 years ago by Markus Bertheau <twanger@…>

So the real problem is that you spam the timeline when you do lots of wiki changes. The proposed solution is very complicated to implement and the user needs to explicitly use the changeset functionality.

I propose a different solution to this problem: Summarize wiki changes by the same person in a short timeframe.

This does not imply that the changes belong together. The timeline spam problem occurs regardless of whether the changes belong together or not, so this is not a flaw.

What do you think?

comment:5 Changed 10 years ago by cmlenz

  • Resolution set to duplicate
  • Status changed from new to closed

This is basically the same as #38 IMHO.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain jonas.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from jonas to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.