former group status not represented correctly

Bug #739972 reported by Teffania
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canon Lore
New
Low
Unassigned

Bug Description

Tamysn Crux spotted this bug, further investigation to verify bug by Teffania Canon.

Only some former subgroups are shown on a branch's record, eg Dubh Thrain is omitted from stormhold's listing of subgroups.
Current listings on stormhold include current subgroups (cairnfell, st barts) and former subgroups where an end date is not known (all others). Dubh Thrain is the only former subgroup with an entered end date and does not occur in listing. Dark skies, a former shire (not subgroup) which became stormhold is not listed - with end date entered. East ridge, a former shire and canton of stormhold (dates not given) is shown. Bryn a Mor a former canton, became isildir became krae Glas is shown.

Checking Rowany's former subgroups:
Cyradd Uchel (became Rowany) - former shire no end date not shown
Amesbury (became Saint Augustine) - former college, no end date, shown

Castellum montanum - close, end date entered - not shown on riverhaven.

So there seems to be a persistant pattern:
*which group it became is not considered
*which group it was a subgroup of deteremines if it is listed as a subgroup or not
*If dates for end of subgroup status are given, it is not listed as a subgroup.

This doesn't seem fair- either all former subgroups should be listed or no former subgroups. Difficulty is some subgroups change eg Krae Glas is a former subgroup of Stormhold, but is no longer. But Krae Glas isn't closed either.
suggestion - either tag all former subgroups as "former subgroup" and display those where the last chronological non-blank end date entry was as a subgroup of that group as well as those with no last date entered, OR display only subgroups where the end date of group status is blank AND field became is blank.

Overall this probably needs an overhaul. Dates may never be known precisely, so how can canonlore autoguess when fuzzy dates are not permitted? probably something rather simpler like current status and parent group might be a better solution for this, with history kept as a fuzzy logic thing - more like a text field that nothing reads, than it's current very cleaver but ultimately not entireely useable design.

Teffania (teffania)
Changed in canonlore:
importance: Undecided → Low
Revision history for this message
Paul Harrison (paul-francis-harrison) wrote :

There is a related issue determining the members to list in a branch's OP.

Problem is in canon-branch.php, in GetBranch and GetSubbranches. These only look at history records without an end date. The "became" field has no effect.

A possible immediate solution would be:

- if a branch "became" another branch, it is treated as a subbranch

- only if "became" is NULL, history record with no end date is used

(Yikes. The meaning of a NULL history end date changes based on "became" being NULL!)

The branch could additionally display all former subgroups (even still-active groups).

I like the idea of history being text.

Revision history for this message
Canon Herald (canon-lochac) wrote : Re: [Bug 739972] Re: former group status not represented correctly

On 24 March 2011 20:54, Paul Harrison <email address hidden> wrote:
> There is a related issue determining the members to list in a branch's
> OP.
>
> Problem is in canon-branch.php, in GetBranch and GetSubbranches. These
> only look at history records without an end date. The "became" field has
> no effect.
>
> A possible immediate solution would be:
>
> - if a branch "became" another branch, it is treated as a subbranch

not entirely true - I list what the territory became - which for a
shire and even some cantons is not whom the superior of the group was.
 I'm not happy with the became functionality.

> I like the idea of history being text.

As someone who's tried to find out firm dates and decided many do not
exist, It certainly has it's appeal.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.