SDSM:Historical Changes: Difference between revisions

From SMUSwiki
Jump to navigation Jump to search
(Add history item 2024 Apr 18: User Preferences Screen Fails To Display)
(Reformat the page)
Line 6: Line 6:
== Description ==
== Description ==


This part of the '''SDS Modernization (SDSM)''' document enumerates a not
This part of the '''SDS Modernization (SDSM)''' document enumerates a
necessarily exhaustive list of historical changes or improvements that
not necessarily exhaustive list of historical changes or improvements
were made to '''SDS''', made by Darren Duncan if by whom is not otherwise
that were made to '''SDS''', made by Darren Duncan if by whom is not
specified.
otherwise specified.


It exists to provide visibility into historical progress of the
It exists to provide visibility into historical progress of the
Line 21: Line 21:
[[#top|RETURN]]
[[#top|RETURN]]


== SDS Laravel: Fixing Broken Behavior ==
== SDS Laravel: Fixes to Broken Behavior ==


=== 2024 Apr 18: User Preferences Screen Fails To Display ===
=== 2024 Apr 18: User Preferences Screen Fails to Display ===


'''Context:'''
'''Context:''' User <code>darren.duncan</code> attempted to visit their
User Preferences screen, example urls
<code>https://api.smus.ca/User/Preferences</code> (production) and
<code>https://api-latest.smus.ca/User/Preferences</code> (preview).


* User <code>darren.duncan</code> attempted to visit their User Preferences screen, example urls <code>https://api.smus.ca/User/Preferences</code> (production) and <code>https://api-latest.smus.ca/User/Preferences</code> (preview).
'''Observed Behavior:''' In production, a non-graceful generic 500
internal server error message was displayed rather than the expected
User Preferences screen. In preview, the revealed underlying symptom was
that the code line in <code>PreferencesController</code> of
<code>$addresses = $user->guardian->addresses;</code> was dying with
<code>Attempt to read property addresses on null</code>. The problem
occurred for user <code>darren.duncan</code> but not for other users.


'''Observed Behavior:'''
'''Expected Behavior:''' The User Preferences screen should always
display, regardless of whether the user in question is a guardian or has
guardians. If some functionality of the screen is not applicable for
users that aren't or don't have guardians, the screen should either hide
that functionality or explain why it doesn't apply or both.


* In production, a non-graceful generic 500 internal server error message was displayed rather than the expected User Preferences screen.  In preview, the revealed underlying symptom was that the code line in <code>PreferencesController</code> of <code>$addresses = $user->guardian->addresses;</code> was dying with <code>Attempt to read property addresses on null</code>.
'''Applied Solution:''' The dying code line was replaced with code that
only tried to fetch and return an address list when it was valid to do
so, and it returned an empty list otherwise. As a result, the User
Preferences screen never failed to display under this scenario.


* The problem occurred for user <code>darren.duncan</code> but not for other users.
'''Caveat:''' While the User Preferences screen no longer fails to
 
display, as of the completion of this fix, it still remained true that
'''Expected Behavior:'''
the functionality to actually display the fetched address list in
 
question was never implemented, and so for every user, the screen
* The User Preferences screen should always display, regardless of whether the user in question is a guardian or has guardians.  If some functionality of the screen is not applicable for users that aren't or don't have guardians, the screen should either hide that functionality or explain why it doesn't apply or both.
carried the placeholder message <code>Shows address info</code> instead
 
of each individual address.
'''Applied Solution:'''
 
* The dying code line was replaced with code that only tried to fetch and return an address list when it was valid to do so, and it returned an empty list otherwise.  As a result, the User Preferences screen never failed to display under this scenario.
 
'''Caveat:'''
 
* While the User Preferences screen no longer fails to display, as of the completion of this fix, it still remained true that the functionality to actually display the fetched address list in question was never implemented, and so for every user, the screen carried the placeholder message <code>Shows address info</code> instead of each individual address.


[[#top|RETURN]]
[[#top|RETURN]]

Revision as of 15:58, 9 May 2024


This document consists of multiple parts; for a directory to all of the parts, see SDSM:Index.

Description

This part of the SDS Modernization (SDSM) document enumerates a not necessarily exhaustive list of historical changes or improvements that were made to SDS, made by Darren Duncan if by whom is not otherwise specified.

It exists to provide visibility into historical progress of the SDS Modernization (SDSM) project about which this document otherwise mainly just describes the current state of SDS.

This list often but not always corresponds to the list of Git pull requests at https://git.smus.ca which most readers of this document are not privileged to see directly.

RETURN

SDS Laravel: Fixes to Broken Behavior

2024 Apr 18: User Preferences Screen Fails to Display

Context: User darren.duncan attempted to visit their User Preferences screen, example urls https://api.smus.ca/User/Preferences (production) and https://api-latest.smus.ca/User/Preferences (preview).

Observed Behavior: In production, a non-graceful generic 500 internal server error message was displayed rather than the expected User Preferences screen. In preview, the revealed underlying symptom was that the code line in PreferencesController of $addresses = $user->guardian->addresses; was dying with Attempt to read property addresses on null. The problem occurred for user darren.duncan but not for other users.

Expected Behavior: The User Preferences screen should always display, regardless of whether the user in question is a guardian or has guardians. If some functionality of the screen is not applicable for users that aren't or don't have guardians, the screen should either hide that functionality or explain why it doesn't apply or both.

Applied Solution: The dying code line was replaced with code that only tried to fetch and return an address list when it was valid to do so, and it returned an empty list otherwise. As a result, the User Preferences screen never failed to display under this scenario.

Caveat: While the User Preferences screen no longer fails to display, as of the completion of this fix, it still remained true that the functionality to actually display the fetched address list in question was never implemented, and so for every user, the screen carried the placeholder message Shows address info instead of each individual address.

RETURN