View source

From ISFDB

You do not have permission to do that, for the following reasons:

• You do not have permission to edit pages in the Page namespace.
• The action you have requested is limited to users in one of the groups user, Write.

You can view and copy the source of this page:

* 90044 OPEN Per Ahasuerus's note on the community portal, it would be very useful to have the "Recent Edits" submission lists (both approved and rejected) include a link to the same display used for approval, in order to view the change made or proposed. [[User:Mike Christie|Mike Christie]] 04:55, 29 Nov 2006 (CST) :Well, I've worked on this one for 2 days now, and have something that works only for author updates. The problems is that integrating a submission is a destructive process - prior to the submission there is the way a record currently is, and the way the user desires it to be; after submission the desired state becomes the current state, and the old state is lost. As such, simply looking at the old submission records can never work, as the original data it relied on is gone. So, I created a history table that tracks the changes made to specific fields, and augmented the AuthorUpdate tool to insert changes into that table. I then created a history tool which mimics the author update moderation screen, so that you can always see what changes have been made, who made them, who approved them, etc. This would also allow you to see the modification history of a particular record, not unlike the wiki history. :The downside is I estimate that it will take at least my entire 2 week vacation to implement this across all of the editing apps. This is easily more work than the pseudonym change (which I worked on from October 2005 until April 2006). It also requires numerous restructuring of the integration apps in order to gain access to all the required data fields, which tends to destabilize the apps. I will probably have to refactor all of the moderator apps (merging together multiple versions of SQL code into a single unified function), which will also introduce data loss risk. That needs to be done at some point, but I was hoping to refactor one function at a time, and get some runtime after each change. :In general, I feel the feature is extremely useful, but it is also extremely time consuming to implement, as well as highly destablizing. I need to look into whether this is the best use of my time right now. [[User:Alvonruff|Alvonruff]] 07:39, 19 Dec 2006 (CST) ::If it's going to take that long, I agree that it's not a good use of your time. I'm sorry to hear it as it would have been extremely useful. ::One other suggestion I made as a way to approach this was to take the HTML string shown to moderators on the approval screen, and write it to a long text field on the completed submission record. Then the "watchlist" feature would simply be to redisplay this HTML, unprocessed, with a caption saying "here is what was approved". This would (presumably) work for all the different update types, since it would need no intelligence at all about what is actually happening. Are there hidden gotchas in this approach? Or does this sound more doable? ::If not, I'm inclined to go say we should go ahead and start the beta, and rely on the moderators to notify each other if we see data being changed that we know is of interest to others. [[User:Mike Christie|Mike Christie]] [[User_talk:Mike Christie|(talk)]] 07:58, 19 Dec 2006 (CST) :::I think that rather than go off and do a huge project, that I'll do one kind of change at a time: author insert, author delete, author update, author merge, title insert, etc... That way I can also do the moderation refactoring at the same time, and then let the new code simmer a bit, rather than one gigantic destabilization. [[User:Alvonruff|Alvonruff]] 09:35, 19 Dec 2006 (CST) :::With respect to the HTML approach, this is conceptually easy, and certainly not as hard as history support, but from a practical architecture point of view quite a bit of work. The moderator scripts come in two parts: the viewer and the approval script. The viewer knows how to display data, and the approval script knows how to integrate into the SQL database. ::::Problem 1: The approval script doesn't know how to format the data into HTML. Moving the formating code into the approval code is not an approach I like (code duplication and restructuring work). The other method would be to insert HTML whenever the submission is viewed, which isn't my favorite approach either (both approved and rejected submissions will be saved). ::::Problem 2: Let's say we go with the viewer saving the HTML upon viewing. Each of the viewing scripts currently prints the HTML to stdout. All of these apps will need to be changed to build part of an HTML page into a string, and then output that to the screen AND insert it into the database. This will require all the viewer apps to be restructured and altered. These are certainly not insurmountable issues, but it is still considerable work, and I'd rather do the history as it has broader applicability than just looking at old submissions. It can serve as the basis for complete record history, and it's the starting point for implementing watchlisting as well. [[User:Alvonruff|Alvonruff]] 10:29, 19 Dec 2006 (CST) (unindent) Just tried the author update; this looks great. [[User:Mike Christie|Mike Christie]] [[User_talk:Mike Christie|(talk)]] 13:07, 19 Dec 2006 (CST) ==Project Tracking== * Author Update - Completed 12/19/2006. * Author Insert - Under development. Refactored author insert code is in production. * Author Delete - * Author Merge - * Author Record History - * Title Update - * Title Insert - * Title Delete - * Title Merge - * Title Record History - * Publication Update - * Publication Insert - * Publication Delete - * Publication Receord History -

Return to Feature:90044.