Discuss Version 0.50

History of Discuss_Version_0.50
The most recent revision number of this page is 2. It has been viewed 0 time(s). It was last modified Sun Apr 5 20:17:44 UTC 2015 by AaronGraves. There are 18 lines of text, 459 words, 2,607 characters with spaces and 2,157 without. The total page size (including metadata) is 3,200 bytes (3.12 KB)

See all pages that link to Discuss_Version_0.50

2015/04/05
20:17 UTC (current) Revision 2 . . . . AaronGraves (68.106.213.102) – The session ID is going to have to be required. Even if the same user is editing a page, if they change the name field at all, it will then deny their edit.
2015/04/02
14:33 UTC Revision 1 . . . . AaronGraves (69.4.28.21) – A few things will be fixed in this release around page locking.The first thing, if someone from the same IP address (but different user name) was attempting to edit the same page, an and statement was being checked which should have been an or statement. This caused `SetLock()` to call `RefreshLock()` when it shouldn't have. I have corrected this. Unfortunately, if two users from the same (external) IP address (think a school or business network) were modifying the same page at the same time, and neither one was authenticated, then they would clobber each others' edits. The only way around this would be to introduce a session ID or something to that effect. I suppose I'll have to look at this sometime down the road.The other fix was the fact that `DoPostingEditing()` wasn't checking the page lock. Since the edit form shouldn't show a submit button if the page was locked, initially I didn't see this as a problem (I guess?). However, if you wait for the lock to expire and refresh the edit form, you will then have a submit button. But even without that, you could still manually submit the form via other means (I'm looking at you, spambots!). So we'll now check for locks before a new edit can be saved.In furtherance of that, perhaps `DoPostingEditing()` should check to be sure that the page wasn't modified before your edits are submitted. Example: You begin working on Page A, but you're busy doing other things at the same time. So you take a couple of hours to make your edits. Meanwhile, your lock has expired, and somebody else came along and made some edits. If your edits go through when you finally get around to submitting them, you will clobber previous edits. The way I see it, there are two options around this:# Check for edits that took place before yours were submitted, and error out. This is the easiest to implement, however the most frustrating for the guy who spent hours making edits, only to find out that he'll have to do it all over again.# Introduce a diff and merge type system for edit conflicts. You'll be shown a page which outlines the differences between what you've submitted, and what was submitted while you were working on your page. You'll then be able to selectively merge the edits. This is, by far, the most difficult to implement.