arborrow / montserrat

A retreat management application written in Laravel
12 stars 4 forks source link

Relationships: Improve dropdown to limit number of options #541

Open arborrow opened 1 year ago

arborrow commented 1 year ago

Current, when attempting to select an individual Polanco includes both the living and the dead and well basically everyone so that the dropdown is slow to load and unwieldy. It is time to tame the options by starting with a more sane initial limit and then allow various options (lastname, matching details like address, email phone, etc) .

arborrow commented 1 year ago

I have started work on this by creating a filter_by parameter to be used to help filter the names displayed. Currently lastname will show where the lastname is the same, matches uses the ss_order trait to get contact matches factoring in matching emails, phone numbers or addresses. I am thinking perhaps a default option would be to use an alternative last_name. With the number of variables being passed in increasing, it may be a good idea to refactor so that the form receives a request rather than trying to put everything as url params. Looking at the living and the dead, the all option should include both but the default option should be the living. If this changes to a request, we could have a living/dead status input and expand to others.

arborrow commented 1 year ago

First, I decided to convert the add blade to a request (passing variables via request rather than the url). We always know at least one of the contacts for which we are defining the relationship. From the contact page, in the relationships section, we determine the type of relationship that we would like to define. Then we should get a list of probably or available options. Since we are only selecting one piece of data at that point, I have decided to simplify the add page to a single dropdown.

In evaluating the options that should be available, I think it makes sense to define relationships among contacts when looking at an individual (namely: parent/child; husband/wife; sibling/sibling). I'm undecided whether it is desirable to be able to define the relationships with an organization (for example employer or parishioner). If I choose to keep it strictly to individuals, then in the organization request packet I can require a lastname to help ensure that the list of options remains reasonable. I don't think that the list of parishes would be that long but it could be a little cumbersome.

I'm going to solicit feedback from the users to see what they want. For now, I am going to leave the organizational relationships for the individual and recommend that they be defined from the organization side or if they are assigned from the individual side that a name be provided to help limit the results.

arborrow commented 1 year ago

Here is a listing of the various relationships that can be assigned and how they are assigned:

Relationships currently available:

Relationship assigned in other places:

Relationships currently unavailable:

arborrow commented 1 year ago

Some of the issues identified in #330 remain, others have been addressed but there is still some work to do to clean up