This change introduces a bug, that results in non-validating Template field to be existing file unless I change Type field.
- Queries
- All Stories
- Search
- Advanced Search
All Stories
Nov 24 2016
Build #101 finished with UNSTABLE status: http://ci.in-portal.org/job/in-portal-52x/101/
Build #115 finished with UNSTABLE status: http://ci.in-portal.org/job/in-portal-52x_modules/115/
Build #100 finished with UNSTABLE status: http://ci.in-portal.org/job/in-portal-52x/100/
Build #99 finished with UNSTABLE status: http://ci.in-portal.org/job/in-portal-52x/99/
Build #98 finished with UNSTABLE status: http://ci.in-portal.org/job/in-portal-52x/98/
Build #96 finished with FAILURE status: http://ci.in-portal.org/job/in-portal-52x/96/
Build #95 finished with FAILURE status: http://ci.in-portal.org/job/in-portal-52x/95/
Detected bug, when one admin user opens to edit category1 with relatively big TreeLeft/TreeRight numbers. Then second admin user moves subtree, where category1 is a leaf to the zone of smaller TreeLeft/TreeTight numbers. Then, first user saves category1 and old, big TreeLeft/TreeRight numbers becomes saved to the zone of small TreeLeft/TreeRight numbers, breaking Treeleft BETWEEN A AND B logic.
Nov 22 2016
Mentioned above not a bug. Clearing editor area after each step helps to avoid link merging problem.
When editing inline block in adm.console, button "Remove Link" is not available, and this makes problematic to input non-linked text after some link is added to empty editor.
And test plan still doesn't cover direct method usage of DateHelper class.
Requested fixes
Nov 21 2016
Today partially tested part of part 1. Only actions for leaf operation with enabled "Recycle Bin". No bugs found.
Also test plan doesn't have regression testing part, where all changed code is invoked and confirmed, that it works as before (places where you now do Status = ThemeStatus::ACTIVE instead of Enabled = 1.
Nov 20 2016
All length checking code was changed and therefore test plan must include testing of all existing behavior (regression testing), not just the part that was fixed. I guess you can create field declaration with all possible validation options and just confirm, that:
- when array is passed in no validation error happens
- when invalid scalar value (maybe several values needs to be used to match each of validation options) is passed the validation error happens
- when valid scalar value (maybe several values needs to be used to match each of validation options) is passed no validation error happens