Custom Report Sorting Bugs

[mkmurray]

This implies that the temporary record was assigned as a member of one of the elders quorums. I'm curious under what circumstances it would be necessary to create a temporary/nonmember record such that they would show up as a member of an elders quorum. I'm having a hard time imagining a likely scenario.

Yes, this is the case. I don't know if it is on purporse or not. I can try and guess whether it's because of fellowshipping or maybe just an oversight, but it really doesn't matter. The issue is in regard to non-members and custom reports. In fact, it appears it's not necessarily non-members either. It's just any data field that could contain empty data messes up the sortability of the column.

[aebrown]

This implies that the temporary record was assigned as a member of one of the elders quorums. I'm curious under what circumstances it would be necessary to create a temporary/nonmember record such that they would show up as a member of an elders quorum. I'm having a hard time imagining a likely scenario.

A male nonmember who attends church (yes, that happens, and when it does, it's a very good thing) would need to attend some class during the Priesthood portion of the block. If he is included in the Elders Quorum organization, then he would be on class rolls and class lists. Organization lists are often used for contacting people, letting them know about activities or service opportunities. It would be helpful in the fellowshipping of such a nonmember to include him on lists.

[mkmurray]

The problem with custom reports sorting by birthday is definitely related to nonmembers.

...

Somehow as the sort algorithm is processing records, as it comes across a nonmember record, it acts like a "stopper" and the algorithm stops processing the group that has already been processed and starts a new group. It seems like the bug is caused by something like that.

So we've established that this can be caused by nonmember records, as they contain empty data in some fields that are assumed to have data in them. But it appears there may be a possibility that nonmember records would be the only cause of this. It seems like any data field that is empty could potentially mess up the sortability of that column in a custom report.

Are there other data fields we can think of besides birthdate (and its variations) that could be empty and cause sorting bugs in custom reports?

For instance, Priesthood Office would likely not be a problem, correct? (because "Unordained" would be the default value, not empty) Also, I've never had this problem with address or phone numbers; empty data fields have always sorted correctly when these columns were included in a custom report.

[aebrown]

In fact, it appears it's not necessarily non-members either. It's just any data field that could contain empty data messes up the sortability of the column.

I don't see any evidence that this generalization is true. In my testing, blank fields are simply sorted to the top of the list, or records with blank values are excluded from the report (for example, Age). The only problems I see are with fields related to the birthdate: Birthday, Birth Day, Birth Month, and Birth Year. And the only records that cause problems with those fields are various types of temporary records.

Do you have other specific examples of fields where empty data affects the sortability of columns?

[mkmurray]

Do you have other specific examples of fields where empty data affects the sortability of columns?

No, not at the moment. I am trying to see if we can define the scope of this bug (large or small) and identify what the underlying cause really is. I think you are right that we can't jump to conclusions.

I will suggest one more thought...it appears this doesn't quite encompass all blank data fields in general, but I will propose that perhaps there is a concept in the custom reports module of data fields that are allowed to be blank and others that are expected not to be blank. I'm wondering if fields related to birthdate are under that expectation, and also if there are a few other fields that may exhibit this same problem because of such a restriction.

But again, I don't have any specific examples myself. Just trying to encourage a little community brainstorming.

[RossEvans]

But again, I don't have any specific examples myself. Just trying to encourage a little community brainstorming.

Well, speculation is a game that any number can play. I really have nothing of value to add to the discussion, except to wonder what kind of data structure MLS uses under the hood. If it is using any kind of embedded SQL engine, there might be differences in behavior between blank fields and NULLs.

[mkmurray]

Ok, I just heard back from some Church employees. Apparently there was a bug with comparing blank dates against non-blank dates. My assumption is that comparing blank strings (like addresses and phone numbers) against non-blank strings did not have the same problem. Either way, a Church developer fixed this bug and hopefully we'll see it in the next release of MLS (perhaps 3.0.4?).

As for the column sorting, I got the same answer as Alan_Brown gave (the one about manually sorting in reverse order) and a confirmation that only the primary (first) column is sorted by default. Apparently my proposition for sorting all columns by default wasn't strong enough or convincing enough, as it wasn't addressed at all.

[russellhltn]

Normally you'd expect a sort routine to consistently deal with blank fields. However, there is a possibility that it causes a failure in the "compare" operation in the sort algorithm and creates seemingly random results.

The "difference" may have more to do on where the records are in the unsorted stack then property/value of the record itself.

[mkmurray]

Either way, a Church developer fixed this bug and hopefully we'll see it in the next release of MLS (perhaps 3.0.4?).

A further communication indicated that this fix would be in MLS 3.1. Hopefully that version number is the next planned release of MLS.

[aebrown]

A further communication indicated that this fix would be in MLS 3.1. Hopefully that version number is the next planned release of MLS.

I think it's okay to mention that as a beta tester, our stake has been informed that MLS 3.1 beta will be downloaded to our stake sometime soon. So I think it's safe to assume that 3.1 is indeed the next version after 3.0.3.