Account Request Form Upgrade

[fans2619]

This issue keeps track of PRs relating to the account request form upgrade. More info can be found on the wiki at https://github.com/TEAMMATES/teammates/wiki/Account-Request-Form-Upgrade.

[fans2619]

@damithc Good night! I just want to check a few more about the account request form. When you are adding an instructor currently, I guess you only fill in the three fields for every instructor: name, email, institution. So I wonder how you use other information provided: country, home page URL, comments/queries. Are these three for viewing only and won't be edited or stored currently?

[damithc]

@damithc Good night! I just want to check a few more about the account request form. When you are adding an instructor currently, I guess you only fill in the three fields for every instructor: name, email, institution. So I wonder how you use other information provided: country, home page URL, comments/queries. Are these three for viewing only and won't be edited or stored currently?

@fans2619 I use name | email | institution, country

url and comments/queries are used to decide if the request from a legit instructor i.e., you need to display those two to me.

[fans2619]

I use name | email | institution, country

I see. The institution, country seems a little troublesome to deal with. Personally I think you won't need to edit the country field in any way but only the country part in the institution. So I tend to show country again in the pop-up (not editable) and the institution shown can be institution, country (editable). By the way, I just came up with another question: probably we want to keep all the info submitted by a user before it's edited, e.g., original name & edited name.

url and comments/queries are used to decide if the request from a legit instructor i.e., you need to display those two to me.

So url and comments/queries will definitely be shown in a separate pop-up due to space limitation.

[damithc]

I see. The institution, country seems a little troublesome to deal with. Personally I think you won't need to edit the country field in any way but only the country part in the institution. So I tend to show country again in the pop-up (not editable) and the institution shown can be institution, country (editable). By the way, I just came up with another question: probably we want to keep all the info submitted by a user before it's edited, e.g., original name & edited name.

Need both to be editable, if the data is collected as free text. One obvious reason is to fix typos.

Currently, I don't keep the original data (but perhaps the GSheets does that anyway). I'm not sure if it is worth keeping the original data (I can't think of any use).

So url and comments/queries will definitely be shown in a separate pop-up due to space limitation.

That makes my life harder. Figure out a way to show everything without needing further clicks. The current UI can be changed as necessary. It is not very editing-friendly anyway, as you can see below (it's hard to edit when you can see only the first 10 characters of the text):

[fans2619]

Need both to be editable, if the data is collected as free text. One obvious reason is to fix typos.

Okay I think of a way. So I'll provide institution and country separately and a non-editable result showing the combination of the two (institution, country). The result will be updated automatically after you edit either institution or country, and will be used as the final institution.

Currently, I don't keep the original data (but perhaps the GSheets does that anyway). I'm not sure if it is worth keeping the original data (I can't think of any use).

Yup I can't think of any use either but it's just my habit to keep a copy of everything. I don't think it would take too much space in the database, but I'm very fine with not keeping them also, which apparently is easier to implement.

That makes my life harder. Figure out a way to show everything without needing further clicks. The current UI can be changed as necessary. It is not very editing-friendly anyway, as you can see below (it's hard to edit when you can see only the first 10 characters of the text):

I can show each account request like something below, but this will make the home page very long. So to shorten it, it may be possible to collapse requests, if you are okay with?

By the way, I just realised something. If we do not use the Google sheet, you probably won't be able to view a past request any more. It doesn't seem to be feasible to fetch and display all the requests every time when the page is loaded. So do you have any way to quickly locate a past request, either through Search or Log, or you seldom search for a past request? Myself is having some trouble with the search function, maybe caused by my setup.

[damithc]

I can show each account request like something below, but this will make the home page very long. So to shorten it, it may be possible to collapse requests, if you are okay with?

Yes, panels are OK. Again, don't make me click on a panel to see the contents (i.e., they should be expanded by default).

By the way, I just realised something. If we do not use the Google sheet, you probably won't be able to view a past request any more. It doesn't seem to be feasible to fetch and display all the requests every time when the page is loaded. So do you have any way to quickly locate a past request, either through Search or Log, or you seldom search for a past request? Myself is having some trouble with the search function, maybe caused by my setup.

Good enough if they are searchable.

[fans2619]

@damithc How does this look like? It's a simple mockup.

[damithc]

@damithc How does this look like? It's a simple mockup.

Use more realistic data e.g., the actual name/institute is likely a lot longer.

Is this the search results view or account creation page view?

[fans2619]

This is the search results. Long fields will wrap to the next line.

[fans2619]

This mockup was created manually instead of using html. I think the focus here should be on whether the Status and Options are fine.

[damithc]

This is the search results. Long fields will wrap to the next line.

I see. I assume Approve/Reject buttons are not strictly necessary as those actions are primarily done via the account creation page? If yes, can skip them to keep things simple. But if you do provide them here, the 'Edit' button should be here as well?

What does 'Reset Account Request' mean?

I think the focus here should be on whether the Status and Options are fine.

What does 'Registered' mean? Account created? If so, use 'Created' instead, so as not to confuse it with instructor joining TEAMMATES.

What's the purpose of 'Expand/Collapse All' buttons?

Less important, can be omitted in the first version:

1. We might need 'Resend' button here, in case the email doesn't go through for some reason.
2. The Submitted/Rejected/... etc. labels can use different color text (or some other styling) to easily differentiate between them.

[fans2619]

What's the purpose of 'Expand/Collapse All' buttons?

An existing feature. I don't think it's useful though. (By the way, searching for account requests is an existing feature, and I'm just making changes to it.)

What does 'Reset Account Request' mean?

An existing feature again, but let me check it out, because it just came to my mind that instead of providing everything in the search results, probably a "Reset" button is enough to set the status back to "Submitted" so you can process it again on the home page.

What does 'Registered' mean? Account created? If so, use 'Created' instead, so as not to confuse it with instructor joining TEAMMATES.

The term "Registered" is reused from the current (there is a "Registered At" datetime). And "Registered" means an account (not account request) is created. An account is created now when an instructor clicks the "join" link and join the first course. "Created" will be referring to when the account request is created (i.e., when instructor submits the request form). Personally I want to change "Created At" to "Submitted At". However, I think this change can be done last, to reduce the complexity of the data migration. For "Registered", I don't have much opinion on it though. "Joined" may also be a good term to consider.

[fans2619]

1. We might need 'Resend' button here, in case the email doesn't go through for some reason.

I think having a 'Reset' button will also be able to cover this, right? You can approve it again after reset. By the way, the join link is actually displayed in the panel. It can always be manually copied and sent. (It's called "Account Registration Link" now.)

2. The Submitted/Rejected/... etc. labels can use different color text (or some other styling) to easily differentiate between them.

Sure. That can be done last.

[damithc]

The term "Registered" is reused from the current (there is a "Registered At" datetime). And "Registered" means an account (not account request) is created. An account is created now when an instructor clicks the "join" link and join the first course. "Created" is referring to when the account request is created (i.e., when instructor submits the request form). Personally I want to change "Created At" to "Submitted At". However, I think this change can be done last, to reduce the complexity of the data migration. For "Registered", I don't have much opinion on it though. "Joined" may also be a good term to consider.

Let's keep it as 'Registered'. It keep forgetting that the account is created when the instructor joins, which was not the case for most of the the TEAMMATES history. The flow Submitted -> Approved -> Registered makes sense.

I haven't used the 'Reset Account Request' feature yet. Find out what it does. Can keep if it has a useful purpose.
The expand/collapse all can be kept too. It shows the join-link for each request.

[damithc]

1. We might need 'Resend' button here, in case the email doesn't go through for some reason.

I think having a 'Reset' button will also be able to cover this, right? You can approve it again after reset. By the way, the join link is actually displayed in the panel. It can always be manually copied and sent. (It's called "Account Registration Link" now.)

Yes, that works.

[fans2619]

Let's keep it as 'Registered'.

Okay!

[fans2619]

@damithc You may know that there's no country field in the database currently since you always put the country inside institute. As a result, if we want to store institute and country separately, the way of ID generation for an account request needs to be changed. I have actually kind of achieved this separation already, but the solution is very complicated, and it may cause undesired consequence, although it's unlikely if you have been using institute, country all the time so far since we have account request database. The solution is complicated as it requires all the places of identifying an account request to use 3 parameters (email, institute, country) instead of the original 2 parameters (email, institute). This also includes that a new field country needs to be created to the accountrequest core in the Solr search server. So even though this can be achieved, I would still recommend storing institute and country together directly. This means once users submit the form, the two fields will be combined and stored in the database and later on, you will be editing this "final institute" instead of editing both institute and country. For your referece, we store the original institute and country submitted by users as well but there's no need for them to be editable at all. With that said, it's also okay to make them editable, in case they will be used in some way in the future.

[fans2619]

But this can be equivalent to that you edit the institute and country, and we have a combined institute with country stored in the database. I think I'll use this instead. So in the end, the combined still should be stored, in order to make the implementation easier.

[damithc]

@fans2619 I'm fine as long as I can edit both of them after the user has submitted them, when I'm using the admin UI to accept/reject account requests. They don't even have to be presented to me as two separate fields. It is fine if you want to store them a a single field in the database. Does that clear your doubt?

[fans2619]

Yup thanks prof!

[fans2619]

I'm fine as long as I can edit both of them after the user has submitted them, when I'm using the admin UI to accept/reject account requests. They don't even have to be presented to me as two separate fields. It is fine if you want to store them a a single field in the database. Does that clear your doubt?

@damithc I will store them as a single field and throw away the original data submitted. You'll see only one field and edit it directly. This is to save space in the database. However, some cons are that it may make it hard to read if there are "," in the institute and/or country. There's no perfect solution and it seems that saving space and saving cost is more important for us.

[damithc]

@damithc I will store them as a single field and throw away the original data submitted. You'll see only one field and edit it directly. This is to save space in the database. However, some cons are that it may make it hard to read if there are "," in the institute and/or country. There's no perfect solution and it seems that saving space and saving cost is more important for us.

@fans2619 In the case of account requests, the space and cost may not matter much as the number of entities is relatively small. So, you can save as two fields too, if it helps.

[fans2619]

Hmm to be honest, what helps me more is to store as a single field. I just hope that won't make admin's life too difficult. Storing as two fields is the hardest to implement, so it's either 1 (instituteWithCountry only) or 3 (institute, country, instituteWithCountry).

[damithc]

Hmm to be honest, what helps me more is to store as a single field. I just hope that won't make admin's life too difficult. Storing as two fields is the hardest to implement, so it's either 1 (instituteWithCountry only) or 3 (institute, country, instituteWithCountry).

Sure, no objections.

[fans2619]

@damithc Previously (long time ago) we discussed about what to do when another REJECTED account request exists when a user submits the account request form, and we decided to overwrite that account request. However, thinking about it again last night, it may not be a good enough solution because it can cause admin to process the same request again and again. So what if we just ban all submissions if the email%institute conflicts with an existing request, regardless of the status? And we should tell them a request already exists and contact us if in doubt in this case.

[damithc]

@damithc Previously (long time ago) we discussed about what to do when another REJECTED account request exists when a user submits the account request form, and we decided to overwrite that account request. However, thinking about it again last night, it may not be a good enough solution because it can cause admin to process the same request again and again. So what if we just ban all submissions if the email%institute conflicts with an existing request, regardless of the status? And we should tell them a request already exists and contact us if in doubt in this case.

You mentioned earlier that doing so is a minor data leakage as it allows any third party to find out if a certain other person has requested for a TEAMMATES account.

Would adding another status 'Reapplied' help?