-
Notifications
You must be signed in to change notification settings - Fork 4
Issues
Sometimes there's an issue. We'd like to fix it. Here's the WIP page on that. Each issue has a code. Whenever a new code is needed, create a new class type in
1: Access Cards: Active card multiple accounts
This can happen if a card gets re-purposed but not removed from the original account. WinDSX will only let the latest update for a particular card pass through, meaning that whomever had it issued to them last has it under their name in WinDSX. To resolve:
- See if one of the members is not a member. If so, this card was probably recycled and can be removed from the inactive member's account.
- If they are both a member, you will need to determine who the actual card holder is. If someone has two cards on their account and especially if they are the earlier user, they likely were given that access card but whoever gave them the new card only added it to the list instead of removing their original card.
- At the end, each member should have their own unique card.
2: Access Cards: Card holder incorrect name
This one can get tricky. In general, we try to respect people's names. There's two sides to balance here. On one hand, we have had people lie about their identity before and it becomes very difficult to do things like file a police report when you have a false identity. On the other hand, people change their names for all sorts of reasons. The ID check is usually considered the source of truth since that's when we have someone's ID in hand, though sometimes errors can be made then as well. Whatever name is used upon ID check is the name that gets put into the WinDSX system. This issue shows up when that name no longer aligns with the name in WordPress, which is user editable.
Most of our systems auto update to someone's updated name where possible, but because card access logs might actually be used in an investigation, that name change does not occur automatically. The only time this name is seen is if card access was disallowed for some reason and the access team gets an email, or in this issue.
In the event that a name doesn't match, you have to make a judgement call. If it's something akin to a nickname, it's probably fine to just change it in the WinDSX system. If it's an entirely different name, it might be beneficial to reach out and ask about it.
Just for some of the technical details on this:
- Updating their name in WinDSX doesn't change the older log entries. That's why you always search on name id.
- Due to the nature of the webhooks server, all changes made in WordPress are recorded and kept, meaning we can find their old name if need be, it just takes a little more work. This reduces some of the risk here if there's an incident at the cost of time and the fact that you have to know that that's a thing we can do / how to do it.
3: Access Cards: Non member has active card
This one's pretty simple, someone who is not a member has an active card. It's pretty safe to always deactivate the card in this case. This can sometimes be a false alarm if we missed an event that re-activated their membership but other issue types take care of that case. Due to the nature of card holder updates, we only report this issue if we still see the active card in updates and it's been at least 24 hours since we've last seen that card updated by the system.
4: Access Cards: Member card not active
Sort of the inverse of the previous one and most of the same logic applies. It's pretty safe to always activate it, though slightly less safe than deactivating a card. Still, other issue will take care of it if there's a discrepancy.
5: Access Cards: Active card no record
We haven't always used the existing system to manage card access and sometimes people manually edit the card access system. Essentially, we end up with a card holder that we can't match to a WordPress record. The last time this happened, it was when we deprecated the remaining PayPal customers. You either need to match them to a WordPress user (or help them create one that you then sign them up with their card number) or just de-activate the card in WinDSX.
6: Access Cards: Unknown active card for member
I'm not 100% sure what causes this one, I think it's probably an error in the logic flow somewhere that causes a card not in their profile, but that was once in their profile, to re-activate. I usually check card access logs and see if that card is an older card and they're using a different card now. If so, it's easy enough to de-activate the older one in WinDSX.
A customer has a primary email and a list of secondary emails as part of their user metadata. The reason for this is that the primary one exists so our system can send them update on things related to their account. However, sometimes people have their personal email or a denhac email address. It can be helpful to have their personal email address for most account things, but also have their denhac email on some mailing list. Hence, allowing user to have more than one email. Only the primary email is editable by the user.
101: Google Groups: Two members, same email
This really shouldn't happen, but it technically can so I included it as an issue type. This is fixable in the CLI, but really the email in question can only belong to one person so remove it for whomever it doesn't belong to.
102: Google Groups: No member found for email
This issue is relatively common. When a member changes their email, we don't automatically update the google groups. This avoids a potential attack vector where they update their email to one belonging to someone else who has say board email access, and then changes it back to one they own. We don't have protection against that attack vector for someone changing their primary email to another's secondary email, so we have to manually handle group updates when email changes occur.
You have three options, two of them presented by the CLI tool
- Remove email from groups (removing that email from all associated Google groups in denhac)
- Assign email to member (if you know who that email belongs to, you can update it)
- You can manually update the Google group to have their new primary email be the one inside the google groups.
103: Google Groups: Not active member found in groups
This one is pretty simple, someone who is not an active member has their email inside a google group. This should have been handled automatically, but sometimes it doesn't work.
104: Google Groups: Active member not found in groups
This is the opposite of the previous issue, someone who SHOULD have access to certain email lists does not.
These issues are all sorts of fun, but essentially represent that something is different between what an external system thinks the state of the world should be and what the webhooks server thinks the state of the world should be.
201: Internal Consistency: Remote is member but local is not
When we fetch issue data, we pull data based on subscriptions and user memberships. The user membership being active determines if a customer is a member, but we boil that down to a single column to use more easily in our system. These two pieces of data do not match. Usually it's because of issue 212-214 that relate to a user membership not being up to date.
202: Internal Consistency: Cannot find customer
Our local database has a customers table and we're missing this one that's on the remote side, but not here locally.