Edgewall Software

Ticket #566 (closed enhancement: duplicate)

Opened 4 years ago

Last modified 3 years ago

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:

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

Change History

Changed 4 years ago by anonymous

  • component changed from general to wiki
  • severity changed from normal to enhancement

marking enhancement+wiki compoentn

Changed 4 years ago by jonas

  • priority changed from normal to low
  • milestone changed from 0.8 to 0.9

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

Changed 4 years ago by cmlenz

  • milestone deleted

Changed 3 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?

Changed 3 years ago by cmlenz

  • status changed from new to closed
  • resolution set to duplicate

This is basically the same as #38 IMHO.

Add/Change #566 (Changesets for Wiki pages (Prepare wiki-changesets))

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.