we manage multiple client programs for them and they perform some tasks. This issue surrounds assigning a serial number to their individual members each week. Providing that those members of the client have accomplished a small task we give them each week answering a few questions. IF they have answered the questions, then they are "qualified" to receive their serial number. If they have NOT answered their questions, then they are "NOT Qualified" to receive their serial number and they cant enter the number in the field.. Works great no issues. If someone shows up to get a serial number, and they are NOT qualified, all they have to do to "fix' this is to log into their portal and answer the questions we give them and then their status changes to "QUALFIED" One more nuance is that we allow the members of the group to answer the questions multiple times. Their "answers" (validation/qualifications") are good for 7 days as set by a parameter. But we let the users "stack up" answers to the questions if they want. It doesn't matter to us which iteration they choose when assigning a serial number to them. only that they have qualified.
We need to create a table that shows the administrator of that client two things:
1) those members of their group that are QUALIFIED to get their serial number and,
2) those members who are NOT qualified to get their serial number. but registered in the program.
Here is the problem- the individual clients users are either idiots or very clever. They have found a way to exploit our registration system such that they have registered multiple times under multiple alter egos. Why I have no idea in the world. Yet they have. Worst yet is that one member of a client: for example John Smith DOB 1/1/1980 could have registered 4 times! with different emails. Ok kinda hard to prevent that. BUT if John Smith can't remember which alter ego/email address he wants to use/password combination, then he MAY log in to any of his 4 alter egos and answer the questions. Which isn't the worst thing in the world. HOWEVER what has happened in real life is that for sure John Smith has registered 4 times.. BUT for some reason John Smith in 3 alter egos, has properly associated with the specific client group, while his 4th alter ego has NOT properly associated with his Client group. This alter ego is "unassigned".
Because we use authentication based display to ensure that a client only sees its members, then if John Smith's alter ego #4 is the one he answered the questions for, he gets to the top of the line and the Client administrator sees his name on the list (3 times mind you) as being NOT QUALIFIED. John Smith KNOWS he has answered the questions. Further frustrating is that John Smith himself has created this issue arguably. So he argues with the administrator, "no I just answered the questions". Which he did, but the administrator can't tell that because they (as the client) can only see those members associated with their individual group. We can't let the system admins from the client see others, and its hard to train a bunch of people to know what to do..!!
So how can we solve this?
questions-
1) is there a way if one alter ego is properly registered in group "A" for john smith and another alter ego for John Smith carrying the same DOB + first last name and maybe cell number? is registered in another program/group, that we can SHOW the administrator that John Smith is being shown as registered in two groups. THIS WOULD MEAN THAT THE AUTHENTICATION VIEW WOULD HAVE TO HAVE AN EXCEPTION ONLY IF THAT PERSON IS REGISTERED IN MULTIPLE GROUPS TO SHOW WITHIN EITHER ONE OF THOSE GROUPS? Then they could alert John to correct his registration and associate his 4th alter ego with the proper group.
2) we are having a hard time showing those members of a group that are qualified to get their serial number and those that are not on the same table. We are told by support that this is because our account does not support cascading tables and we have to upgrade to get that which is prohibitively expensive for us as a small company.
We temporarily solved this somewhat by giving a tab one with all members of the group and the other one with those of the group that are qualified. But it would be nice to combine those into one table would be preferred.
3) we ARE able to build a table that shows both qualified and not qualified at the same time, but doesn't parse out multiple views or multiple identities/alter egos.. Is it possible to have some type of filter that shows in this table ONLY one alter ego for someone with the same DOB + first + last name for example so that IF There are 4 alter egos registered, only one will show such that our data downstream over time becomes more streamlined? but this then brings into play the issue of john smith above, having 4 alter egos. If we show one, then the one that he happens to log into that week will need to be the one that shows. UGH
WE have so many users now like this and so much historical data frankly its a bit of a mess. We have tried to employ measures to narrow the multiple alter ego/registration going forward but honestly don't think we can clean up what we have..
You can post now and register later.
If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.
Question
chuckiecc
we manage multiple client programs for them and they perform some tasks. This issue surrounds assigning a serial number to their individual members each week. Providing that those members of the client have accomplished a small task we give them each week answering a few questions. IF they have answered the questions, then they are "qualified" to receive their serial number. If they have NOT answered their questions, then they are "NOT Qualified" to receive their serial number and they cant enter the number in the field.. Works great no issues. If someone shows up to get a serial number, and they are NOT qualified, all they have to do to "fix' this is to log into their portal and answer the questions we give them and then their status changes to "QUALFIED" One more nuance is that we allow the members of the group to answer the questions multiple times. Their "answers" (validation/qualifications") are good for 7 days as set by a parameter. But we let the users "stack up" answers to the questions if they want. It doesn't matter to us which iteration they choose when assigning a serial number to them. only that they have qualified.
We need to create a table that shows the administrator of that client two things:
1) those members of their group that are QUALIFIED to get their serial number and,
2) those members who are NOT qualified to get their serial number. but registered in the program.
Here is the problem- the individual clients users are either idiots or very clever. They have found a way to exploit our registration system such that they have registered multiple times under multiple alter egos. Why I have no idea in the world. Yet they have. Worst yet is that one member of a client: for example John Smith DOB 1/1/1980 could have registered 4 times! with different emails. Ok kinda hard to prevent that. BUT if John Smith can't remember which alter ego/email address he wants to use/password combination, then he MAY log in to any of his 4 alter egos and answer the questions. Which isn't the worst thing in the world. HOWEVER what has happened in real life is that for sure John Smith has registered 4 times.. BUT for some reason John Smith in 3 alter egos, has properly associated with the specific client group, while his 4th alter ego has NOT properly associated with his Client group. This alter ego is "unassigned".
Because we use authentication based display to ensure that a client only sees its members, then if John Smith's alter ego #4 is the one he answered the questions for, he gets to the top of the line and the Client administrator sees his name on the list (3 times mind you) as being NOT QUALIFIED. John Smith KNOWS he has answered the questions. Further frustrating is that John Smith himself has created this issue arguably. So he argues with the administrator, "no I just answered the questions". Which he did, but the administrator can't tell that because they (as the client) can only see those members associated with their individual group. We can't let the system admins from the client see others, and its hard to train a bunch of people to know what to do..!!
So how can we solve this?
questions-
1) is there a way if one alter ego is properly registered in group "A" for john smith and another alter ego for John Smith carrying the same DOB + first last name and maybe cell number? is registered in another program/group, that we can SHOW the administrator that John Smith is being shown as registered in two groups. THIS WOULD MEAN THAT THE AUTHENTICATION VIEW WOULD HAVE TO HAVE AN EXCEPTION ONLY IF THAT PERSON IS REGISTERED IN MULTIPLE GROUPS TO SHOW WITHIN EITHER ONE OF THOSE GROUPS? Then they could alert John to correct his registration and associate his 4th alter ego with the proper group.
2) we are having a hard time showing those members of a group that are qualified to get their serial number and those that are not on the same table. We are told by support that this is because our account does not support cascading tables and we have to upgrade to get that which is prohibitively expensive for us as a small company.
We temporarily solved this somewhat by giving a tab one with all members of the group and the other one with those of the group that are qualified. But it would be nice to combine those into one table would be preferred.
3) we ARE able to build a table that shows both qualified and not qualified at the same time, but doesn't parse out multiple views or multiple identities/alter egos.. Is it possible to have some type of filter that shows in this table ONLY one alter ego for someone with the same DOB + first + last name for example so that IF There are 4 alter egos registered, only one will show such that our data downstream over time becomes more streamlined? but this then brings into play the issue of john smith above, having 4 alter egos. If we show one, then the one that he happens to log into that week will need to be the one that shows. UGH
WE have so many users now like this and so much historical data frankly its a bit of a mess. We have tried to employ measures to narrow the multiple alter ego/registration going forward but honestly don't think we can clean up what we have..
Any ideas here would be most welcome'
thanks
Link to comment
Share on other sites
1 answer to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.