|
Sat 09 Dec 2006 06:23:29 PM UTC, comment #7:
> if we removed update point P, we are lost
Yes, but we could e.g. forbid submitting three-day-old (or so) forms at all. And remove points only when all generated for it forms are too old anyway.
> if we are still checking with point P we miss point Q
No, I meant to compare this: current state X with point P state X and submitted state X with point P state X. If both compares indicate changes, we have a conflict: a state is changed in both "trunk" and by submitter, who bases his changes on point P.
|
Sat 09 Dec 2006 06:12:34 PM UTC, comment #6:
> Text area values (at least for comments) need not be tracked at all. There cannot be conflicts in multi-value fields like comments.
In the cookbook, it can. It can also in custom text areas. But, granted, we are talking about rare cases here.
> Advantage over my last proposed option is less server-side overhead and no possibility for a DoS attack. It is still more difficult than including relevant data to the form in hidden fields, though.
It is a nice idea but it would get messy if two people does conflicting posts. I mean you can have:
- guy A that open a form, then it is update point P
- guy B that open the same form, it is still update point P as nothing changed
- guy A submits changing field F to FA and reopen the form, we are at update point Q
- guy B submits changing field F to FB...
- if we removed update point P, we are lost
- if we are still checking with point P we miss point Q.
- If we deal with point P, Q, we may also check for R, S, T etc, and we actually implemented a full history versioning system.
Quite hard :)
|
Sat 09 Dec 2006 06:02:13 PM UTC, comment #5:
Text area values (at least for comments) need not be tracked at all. There cannot be conflicts in multi-value fields like comments.
Yet one more approach is to merge full versioning and server-side storage of item states. There are some well-defined "update points" when someone submits a form. So, you could save state at update point when another form is generated, but only if it is not saved yet. Obviously, states should be discarded after some time for this to be different in any way from full versioning.
Advantage over my last proposed option is less server-side overhead and no possibility for a DoS attack. It is still more difficult than including relevant data to the form in hidden fields, though.
|
Sat 09 Dec 2006 05:51:23 PM UTC, comment #4:
Actually, Yves suggested this already, but the work needed to do somehow also means implementing versioned history, but of forms instead of changes, which would be hard, have the problem you said, but would actually not have the nice option to get a snapshot of an item at a given time.
You are right that the easy way described in comment #1 will obviously increase the size of forms and the size of posted data. But I guess this will be acceptable in most cases, as textarea are rare, and others fields only implies a few characters.
|
Sat 09 Dec 2006 05:44:28 PM UTC, comment #3:
One more way is to track changes on server side is by saving states each time a form is generated. Advantages are: somewhat less HTTP traffic; additional resistance against malicious submits (which is probably not needed anyway since users can still override statuses.) Disadvantages are: less straightforward implementation; possibility of DOS (or at least storage filling) attack by asking to generate lots of forms; need for heuristic for when to discard data for forms that have never been submitted.
This is most likely not worth it, but I'll just mention it as another option.
|
Sat 09 Dec 2006 05:39:09 PM UTC, comment #2:
I think your solution is fine and much easier to implement than versioning all statuses.
|
Sat 09 Dec 2006 04:43:18 PM UTC, comment #1:
Apart from versioning update (which in itself could be nice, but though to implement), the only alternative option I can think of is to send in hidden fields the content of the fields as they we exactly, so we would now exactly if the user tried to change something or not.
- If the user did not change the field and it changed in the database, we ignore what he did
- If the user did change the field that also changed in the db, we reprint the form like we would for a missing mandatory field, asking him to reselect what he wants
|
Sat 09 Dec 2006 04:39:44 PM UTC, original submission:
From https://savannah.cern.ch/bugs/?21477
>2006-11-17 09:44, comment #1:
>Unfortunately, to prevent this we should register the exact status of the item somewhere each time someone create a form, to be able to crosscheck afterwards what was really changed and what has not changed.
>
>Otherwise, we have no way to determine that a value in the form should not override the one in the database (None is valid value too).
>
>In fact, it would mean implementing a versioned approach of item history.
>
>The overhead to avoid this problem seems gigantic to me. How often this happen and how problematic it is?
>
> 2006-11-10 13:48, original submission:
> If two people are using Savannah at the same time, all the settings of the old user are overwritten, e.g. user_1 and user_2 both start to edit bug information at the same time.
>
> If a user_1 fills out fields "Configuration Changes" with "Must be done" and submits the changes the field is set. As user_2 still has the old values when submitting, e.g. an empty field, once he submits, the values are set back to "empty".
>
> It should be checked if the current version is the latest one (like CVS does).
>
> Example: Patch 899 glite middleware.
+ from bug #7972
> Yes, I used an old form. This is an important issue if it overrides changes. E.g. Bugzilla tracks it fine --- it shows a page about conflict with several options, like "post the comment only", "discard everything" or "apply my changes fully".
|
Related Recipes:
Savane - Tasks: task #4226, should check latest update /...