You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Compass, various user roles have access to members in their hierarchy, but different fields are visible, and the structure of the HTML can also vary.
Initially, this can be mitigated with (tightly scoped) try/except blocks, to suppress errors or return None. Longer term, we should consider documenting what we expect to find for a given role, and raising an error or warning if that is not visible (e.g. date of birth for an Administrator role, etc.).
We should also likely add a flag to supress or raise errors for use in production code -- open to dicussion on if it is how to supress errors, and how to communicate which errors have been supressed.
We should also start to test the code -- we can unit test some of the functions that don't integrate with Compass, but for the scraper classes we should try to do some sort of mocking/faking -- perhaps by saving various examples of the returned HTML and parameterising the personal data (invalid phone numbers, missing data etc.). For now, we should gather examples of member IDs where errors occour.
Errors examples:
I ... was encountering exceptions within the xpath queries ... when Compass permissions weren't rendering fields (i.e. Religion).
any 'proper' testing suite would involve all possible permissions groups etc etc.
I think perhaps useful though where errors have occured to save the response.content str (bytes), and with redaction of data we could use these in some form?
Creating an issue with relevant comments from the-scouts/compass-interface-core#1.
Narrative
In Compass, various user roles have access to members in their hierarchy, but different fields are visible, and the structure of the HTML can also vary.
Initially, this can be mitigated with (tightly scoped)
try/except
blocks, to suppress errors or returnNone
. Longer term, we should consider documenting what we expect to find for a given role, and raising an error or warning if that is not visible (e.g. date of birth for an Administrator role, etc.).We should also likely add a flag to supress or raise errors for use in production code -- open to dicussion on if it is how to supress errors, and how to communicate which errors have been supressed.
We should also start to test the code -- we can unit test some of the functions that don't integrate with Compass, but for the scraper classes we should try to do some sort of mocking/faking -- perhaps by saving various examples of the returned HTML and parameterising the personal data (invalid phone numbers, missing data etc.). For now, we should gather examples of member IDs where errors occour.
Errors examples:
@rglss, the-scouts/compass-interface-core#1 (comment)
@rglss, the-scouts/compass-interface-core#1 (comment)
@rglss, the-scouts/compass-interface-core#1 (comment)
@rglss, the-scouts/compass-interface-core#1 (comment)
Testing comments
@AA-Turner, the-scouts/compass-interface-core#1 (comment)
@AA-Turner, the-scouts/compass-interface-core#1 (comment)
The text was updated successfully, but these errors were encountered: