Issue #SCB2623 () Attribute sequence gets duplicate numbers

Activity report on

  *Defect SCB2623 - Attribute sequence gets duplicate numbers *

  Scarab Link: http://www.solitone.org/scarab/issues/id/SCB2623
  Module: Scarab


  Activity generated by Hussayn Dabbous ([email protected]) at 02/14/2009 16:26

  *Reasons for the changes*


  *Personnel changes*
  - Assigned to: dabbous ()

-------------------------------------------------------------------------------
  *Comments*
  - By Hussayn Dabbous - 02/14/2009 16:38 ---
  "The effect can be reproduced by disabling an option in the global attributes section.\\
In that case the logical order of the remaining options gets wrong, because the disabled\\
option is still counted as existant and thus it occupies a place in the order list.

the problem is fixed in trunk (rev 10692) and here is an excerpt of the relevant method documentation:

{{{
Method AbstractScarabModule:getRModuleOptions(Attribute, IssueType , boolean )
Returns a list of Attribute options. One caveat here is, that it is possible
to disable options in the global attributes area. But if an option is disabled,
its order-place(!) is still taken into account. Thus the order values returned
here are well sorted from lower to higher, but not necessarily consecutively
positioned from 1 to #ofOptions
 
Another caveat is, that this method also allows for only retrieving the active 
options, where "active" can be defined on a per module/issue type basis. Also 
here we can possibly end in an ordered but not consecutive list of options.
 
Now this method takes care of thiese caveats and fixes the effect by readjusting 
the element order starting at position 1 and counting up to the number Of Options
available in the result set, thus it is now guaranteed that the options in the 
resultset get a meaningfull and consecutive order value.

The following table illustrates, what i mean. The numbers denote the value of the
order attribute of the RModuleOptions in each of the 2 lists:

Assume, option 2 has been disabled in the global attribute section, so it does not
appear in the allRModuleOptions list. Furthermore option 6 has been marked as inactive
in the current module/issuetype context , so it will be filtered out in the 
resultRModuleOptions. The algorythm as it is implemented now resolves the order 
values as follows:
}}}

|allRModuleOptions | resultRModuleOptions|
|        1                 |             1                |
|        3                 |             2                |
|        4                 |             3                |
|        5                 |             4                |
|        6                 |                               | this element is filtered out.
|        7                 |             5                |
"

  - By Hussayn Dabbous - 02/14/2009 16:31 ---
  "The effect can be reproduced by disabling an option in the global attributes section.\\
In that case the logical order of the remaining options gets wrong, because the disabled\\
option is still counted as existant and thus it occupies a place in the order list.

the problem is fixed in trunk (rev 10692) and here is an excerpt of the relevant method documentation:

{{{
Method AbstractScarabModule:getRModuleOptions(Attribute, IssueType , boolean )
Returns a list of Attribute options. One caveat here is, that it is possible
to disable options in the global attributes area. But if an option is disabled,
its order-place(!) is still taken into account. Thus the order values returned
here are well sorted from lower to higher, but not necessarily consecutively
positioned from 1 to #ofOptions
 
Another caveat is, that this method also allows for only retrieving the active 
options, where "active" can be defined on a per module/issue type basis. Also 
here we can possibly end in an ordered but not consecutive list of options.
 
Now this method takes care of thiese caveats and fixes the effect by readjusting 
the element order starting at position 1 and counting up to the number Of Options
available in the result set, thus it is now guaranteed that the options in the 
resultset get a meaningfull and consecutive order value.

The following table illustrates, what i mean. The numbers denote the value of the
order attribute of the RModuleOptions in each of the 2 lists:

Assume, option 2 has been disabled in the global attribute section, so it does not
appear in the allRModuleOptions list. Furthermore option 6 has been marked as inactive
in the current module/issuetype context , so it will be filtered out in the 
resultRModuleOptions. The algorythm as it is implemented now resolves the order 
values as follows:
}}}

|allRModuleOptions | resultRModuleOptions|
|        1                 |             1                |
|        3                 |             2                |
|        4                 |             3                |
|        5                 |             4                |
|        6                 |                               | this element is filtered out.
|        7                 |             5                |
"

  - By Hussayn Dabbous - 02/14/2009 16:38 ---
  "The effect can be reproduced by disabling an option in the global attributes section.\\
In that case the logical order of the remaining options gets wrong, because the disabled\\
option is still counted as existant and thus it occupies a place in the order list.

the problem is fixed in trunk (rev 10692) and here is an excerpt of the relevant method documentation:

{{{
Method AbstractScarabModule:getRModuleOptions(Attribute, IssueType , boolean )
Returns a list of Attribute options. One caveat here is, that it is possible
to disable options in the global attributes area. But if an option is disabled,
its order-place(!) is still taken into account. Thus the order values returned
here are well sorted from lower to higher, but not necessarily consecutively
positioned from 1 to #ofOptions
 
Another caveat is, that this method also allows for only retrieving the active 
options, where "active" can be defined on a per module/issue type basis. Also 
here we can possibly end in an ordered but not consecutive list of options.
 
Now this method takes care of thiese caveats and fixes the effect by readjusting 
the element order starting at position 1 and counting up to the number Of Options
available in the result set, thus it is now guaranteed that the options in the 
resultset get a meaningfull and consecutive order value.

The following table illustrates, what i mean. The numbers denote the value of the
order attribute of the RModuleOptions in each of the 2 lists:

Assume, option 2 has been disabled in the global attribute section, so it does not
appear in the allRModuleOptions list. Furthermore option 6 has been marked as inactive
in the current module/issuetype context , so it will be filtered out in the 
resultRModuleOptions. The algorythm as it is implemented now resolves the order 
values as follows:
}}}

|allRModuleOptions | resultRModuleOptions|
|        1                 |             1                |
|        3                 |             2                |
|        4                 |             3                |
|        5                 |             4                |
|        6                 |                               | this element is filtered out.
|        7                 |             5                |
"

  - By Hussayn Dabbous - 02/14/2009 16:34 ---
  "The effect can be reproduced by disabling an option in the global attributes section.\\
In that case the logical order of the remaining options gets wrong, because the disabled\\
option is still counted as existant and thus it occupies a place in the order list.

the problem is fixed in trunk (rev 10692) and here is an excerpt of the relevant method documentation:

{{{
Method AbstractScarabModule:getRModuleOptions(Attribute, IssueType , boolean )
Returns a list of Attribute options. One caveat here is, that it is possible
to disable options in the global attributes area. But if an option is disabled,
its order-place(!) is still taken into account. Thus the order values returned
here are well sorted from lower to higher, but not necessarily consecutively
positioned from 1 to #ofOptions
 
Another caveat is, that this method also allows for only retrieving the active 
options, where "active" can be defined on a per module/issue type basis. Also 
here we can possibly end in an ordered but not consecutive list of options.
 
Now this method takes care of thiese caveats and fixes the effect by readjusting 
the element order starting at position 1 and counting up to the number Of Options
available in the result set, thus it is now guaranteed that the options in the 
resultset get a meaningfull and consecutive order value.

The following table illustrates, what i mean. The numbers denote the value of the
order attribute of the RModuleOptions in each of the 2 lists:

Assume, option 2 has been disabled in the global attribute section, so it does not
appear in the allRModuleOptions list. Furthermore option 6 has been marked as inactive
in the current module/issuetype context , so it will be filtered out in the 
resultRModuleOptions. The algorythm as it is implemented now resolves the order 
values as follows:
}}}

|allRModuleOptions | resultRModuleOptions|
|        1                 |             1                |
|        3                 |             2                |
|        4                 |             3                |
|        5                 |             4                |
|        6                 |                               | this element is filtered out.
|        7                 |             5                |
"

  - By Hussayn Dabbous - 02/14/2009 16:39 ---
  "The effect can be reproduced by disabling an option in the global attributes section.\\
In that case the logical order of the remaining options gets wrong, because the disabled\\
option is still counted as existant and thus it occupies a place in the order list.

the problem is fixed in trunk (rev 10692) and here is an excerpt of the relevant method documentation:

{{{
Method AbstractScarabModule:getRModuleOptions(Attribute, IssueType , boolean )
Returns a list of Attribute options. One caveat here is, that it is possible
to disable options in the global attributes area. But if an option is disabled,
its order-place(!) is still taken into account. Thus the order values returned
here are well sorted from lower to higher, but not necessarily consecutively
positioned from 1 to #ofOptions
 
Another caveat is, that this method also allows for only retrieving the active 
options, where "active" can be defined on a per module/issue type basis. Also 
here we can possibly end in an ordered but not consecutive list of options.
 
Now this method takes care of thiese caveats and fixes the effect by readjusting 
the element order starting at position 1 and counting up to the number Of Options
available in the result set, thus it is now guaranteed that the options in the 
resultset get a meaningfull and consecutive order value.

The following table illustrates, what i mean. The numbers denote the value of the
order attribute of the RModuleOptions in each of the 2 lists:

Assume, option 2 has been disabled in the global attribute section, so it does not
appear in the allRModuleOptions list. Furthermore option 6 has been marked as inactive
in the current module/issuetype context , so it will be filtered out in the 
resultRModuleOptions. The algorythm as it is implemented now resolves the order 
values as follows:
}}}

|allRModuleOptions | resultRModuleOptions|
|        1                 |             1                |
|        3                 |             2                |
|        4                 |             3                |
|        5                 |             4                |
|        6                 |                               | this element is filtered out.
|        7                 |             5                |
"

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=458&dsMessageId=1158509

To unsubscribe from this discussion, e-mail: [[email protected]].