In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!
Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories
  

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Type Reproducibility Date Submitted Last Update
0001047 [In-Portal CMS] Data Management bug report always 2011-05-04 15:26 2011-10-21 12:24
Reporter alex View Status public Project Name In-Portal CMS
Assigned To erik Developer
Priority normal Resolution won't fix Fixed in Version 5.2.0
Status closed Product Version 5.1.2 Target Version 5.2.0
Time EstimateNo estimate
Summary 0001047: Misplaced field format validation code
Description In-Portal has ability to validate value in the field using given regular expression (regexp option in field definition).

All works fine, unless you need to change field value (not on form, but in code) before validation takes place.

To solve that problem I'm proposing to move processing of "regexp" option from kFormatter class into kDBItem class.
Additional Information This "regexp" option is specified in unit config file, like "core/units/users/users_config.php" in "Fields" array, e.g.

'Fields' => Array (
    'Login' => Array ('type' => 'string', 'formatter' => 'kFormatter', 'regexp' => '/^user.*$/', 'default' => ''),
),

This will force all new users to have "user" in front of their login name to be entered before registration could continue.
Tags No tags attached.
Reference https://groups.google.com/d/topic/in-portal-bugs/uWeBloFOzio/discussion
Change Log Message Moved "regexp" field option processing to kDBItem class
Estimate Points 0
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
User avatar (0004085)
alex (manager)
2011-10-21 12:24

 Together with Erik we agreed on fact, that this task shouldn't be implemented, since error set by formatter (invalid format) take precedence over any custom error, that can be set in OnBeforeItem... event.

For example if:

1. word is entered in a numerical field;
2. formatter validation checks, that field value is a number;
3. custom validation checks, that field value is greater, then 10.

This way checking if field value is greater, then 10 (custom validation) doesn't make sense if field value is a word (formatter validation).

- Issue History
Date Modified Username Field Change
2011-10-21 12:24 alex Note Added: 0004085
2011-10-21 12:24 alex Status needs work => closed
2011-10-21 12:24 alex Time Estimate Removed 1 =>
2011-10-21 12:24 alex Resolution open => won't fix
2011-10-21 12:24 alex Fixed in Version => 5.2.0
2011-10-21 09:09 Dmitry Assigned To => erik
2011-10-21 09:09 Dmitry Status active => needs work
2011-09-26 04:52 alex Time Estimate Added 1
2011-09-23 20:54 Dmitry Target Version Icebox => 5.2.0
2011-05-04 15:26 alex New Issue
2011-05-04 15:26 alex Reference => https://groups.google.com/d/topic/in-portal-bugs/uWeBloFOzio/discussion
2011-05-04 15:26 alex Change Log Message => Moved "regexp" field option processing to kDBItem class

Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories
  

Web Development by Intechnic
In-Portal Open Source CMS
In-Portal Open Source CMS
Copyright © 2000 - 2009 MantisBT Group

Powered by Mantis Bugtracker