add fields about mail aliases in wild apricot member profile

[benoitc]

As discussed in our last meeting, we decided to add 2 fields to the user profile in wild apricot to let the user choose their mail preferences:

• [ ] alias or mailbox
• [ ] address mail

[starbelly]

Might be helpful to add a boolean here, email_active. I believe address should work like that, but an explicit boolean might be good to have and it can't hurt either.

[benoitc]

Did we make any progress on it? If you need some help, i can help on it.

[peerst]

Yes actually I need some help. The field names are specified as for being used by a program.

I need the actual Names that are shown to the members. They should be as self explanatory as possible. In addition I need a paragraph of instructions per new filed which tell users more details.

So we are talking about UX for our Members because these fields show up immediately as soon as I activate them (we might only add them to a small test subset until they work, who would be in this set?)

Also for each new Field: User read access, user edit access

And the datatype (see attached screenshot for what is available)

[benoitc]

hrm

what about the following

• Address mail: <TEXT INPUT> , pre-filled with user@erlef.org
• <RADIO BUTTON> Mail is an alias

in bold is the text (or name) for each fields. If checked the radio button will means the user want a mail alias. A text input is used with the address mail, prefilled with user@erlef.org .

[peerst]

Without further explanation I don't understand what it means. And I was there when we discussed it (too long for me to remember) a while ago.

So I guess the UX is not perfect yet

And I'm not sure I can pre-fill things

[peerst]

Again as I said for each field I need

1. Name (visible so it should be as clear as possible self explaining)

2. Description (further explanation)

3. Type

4. User visible yes/no?

5. User editable yes/no?

[benoitc]

I fixed the comment. Gidthub was not displaying the type.

How will it appear on the user page?, instead of name i am suggesting labels like the one above.

[benoitc]

so did it answer to your question? where are we on this topic?

To clarify things again, what we are talking since some months is having the following two simple fields on the member page:

1. email address choice with the initially proposed label "Address mail", this is a text input with a suggestion. Possibly, it should be tested if it's unique across the database
2. choice if it's an alias to their main address or a a plain email address. It should probably be an unchecked button labelled as "Mail is an alias".

Example of view on the page:

*Address mail*: <TEXT INPUT> , pre-filled with user@erlef.org
<RADIO BUTTON> *Mail is an alias*

Anyway I can have a look in wild apricot itself if you don't have time, can you open me an access to it? You can also ping me the other way around, if you have more questions .

[starbelly]

Note: All we need is a field to hold the email address. Either pre-populated or populated remotely via the web app.

[starbelly]

I added the following fields which are internal only and only available for the following levels:

• Annual Supporting Membership
• Board
• Fellow
• Lifetime Supporting Membership
• Managing and Contributing

Fields:

• has_mail_alias
  • boolean, set to true or false, indicates whether a user has a mail alias
• has_mail_box
  • boolean, set to true or false, indicates whether a user has a full blown mail box
  • erlef_mail_address self-explanatory, the users requested erlef_mail_address

We can't constrain these of course, so it will be the responsibility of the website application to keep them constrained.

Rules:

• has_mail_alias and has_mail_box booleans, only one can be true, if both are true this is a fatal error
• erlef_mail_address, no specific constraints.

[peerst]

Are these variables, that unlike the ones mentioned further up in the ticket, that will not be seen by the users?

[starbelly]

@peerst that is correct. Members will be able to see the values in the website app.

Edit: I suppose we could surface them in wildapricot profile too as read-only, not sure it's worth it. Thoughts?

Edit: Note that if we want to surface them in wildapricot member profile we need two sets. One set that is read-only and one set that is internal only. The idea here is :

• users will opt in for the address via the website itself
• notification will be sent out to the infra group
• the notification sent out will have two links
  • one link that allows an admin to see the request
  • the other link will automagically mark the request as in progress and assigns the request to the admin who clicked the link (this is how we prevent each other from working on the same request)
    • The request is fulfilled (either manually or automatically, looks to be manual to start with)
    • The admin goes back to the request in the admin section of the website, marks the requests as fulfilled, enters the temporary password for the newly created address (unless it's an alias) and a notification is sent to the member with instructions for logging in, resetting the password, etc.
    • If the request is just for an alias, then no need to enter temporary password or a need to send instructions, we will just send the member an email stating the alias is in place.