Core: Add a Contact Page feature

[dcsjapan]

The other day @jordanjay29 and I were discussing how Flarum could provide for the needs of users who need to contact the forum staff but can't use their account for some reason or another, e.g.

• Users whose accounts have been suspended as a result of voluntary account deactivation
• Users who wish to appeal a non-voluntary account suspension
• Users who can't get their account verified because they entered an invalid email address

and so on. Currently such users are forced to either (a) create a second account, or (b) contact the forum staff via some outside medium (email, Twitter, etc.). The trouble with these methods is that they provide no easy way to confirm that the person making the inquiry is in fact the user who created the account in question. We concluded it would be best if Flarum offered some point of contact that could leverage the existing account information to facilitate confirmation of the inquirer's identity.

There's no question that this "contact page" should be done as an extension. I'm proposing it be added as a bundled extension mainly because this feature would be useful for the Flarum Community site.

User Interface

The contact page, available at a URL such as forum.example.com/contact, would essentially be a form consisting of the following elements:

• A dropdown list used to specify the type of inquiry being made
• One or more fields used to supply information identifying the user
• A text box where the user can enter the detailed inquiry message
• An optional reCAPTCHA test
• A button used to submit the inquiry

There would also have to be a mechanism for testing the validity of the information provided and asking the user to complete any fields that were left blank, etc.

Configuration

The admin interface would consist of little more than a set of tools that can be used to create a variety of "recipes" for building the contact form. The main page of this interface would consist of a list of existing recipes and three buttons: Add Recipe, Edit Recipe, and Delete Recipe.

Clicking either of the first two buttons will open a modal dialog where the admin can configure the recipe being added or edited. The settings in this modal dialog should include the following elements:

---

• Type of Inquiry

  This is a text box where the admin will enter the "name" of the recipe. The recipe names entered here are used to populate the dropdown list in the user interface.

• Require Authentication

  This is a toggle that can be used to constrain the display of the recipe to users who are currently logged in. It is used for inquiry types that shouldn't be made available to unauthenticated users.

• Ask For

  This is a series of toggles that specify which fields the user will be required to complete in order to send the inquiry. The selection of toggles should probably include the following:

  • Your Name - Enables a text field where the user can type his/her real name.
  • Contact Email - Enables a text field where the user can type a contact email address.
  • Username - Enables a text field that must match the account username.
  • Account Email - Enables a text field that must match the address registered to the account.
  • Password - Enables a text field that must match the password for the account.
  • reCAPTCHA - Enables the optional reCAPTCHA test displayed at the bottom of the form.

  The more options we add here, the more flexible the contact page will be. It should be obvious that the admin will not want to enable all of these options for most recipes; instead, it will be necessary to choose the appropriate items for the inquiry type in question. For example:

  • A user who wants to reactivate a deactivated account will not be able to supply a valid value for the Account Email field, because that information will be nullified during account deactivation.
  • A user who can't verify their account because they entered an invalid email address during account creation may also not be able to supply a valid value for this field.

  In such cases, the recipe should ask for a Username and a Password and use this information to determine whether the user belongs to the account in question. (If deactivated users and unvalidated users are allowed to log in, then the admin can simply Require Authentication for the recipe instead.) The recipe could also ask for a Contact Address so the admin will have a way to contact the user regarding the inquiry.

  To take another example:

  • A visitor to the forum will (for obvious reasons) not be able to supply valid values for the Username, Account Email, or Password fields.

  If an admin wants to allow pre-registration inquiries, this can be accommodated by a recipe that combines the Your Name, Contact Address, and reCAPTCHA options.

  Any system that offers this much flexibility may well be confusing to admins, but ultimately I think this system will prove more useful than a more specific contact page designed with to handle only a limited set of inquiry types. To ameliorate the confusion, we can think about adding some way to create a few preconfigured recipes when the software is first installed.

• Send Email To

  This is a dropdown list, supplied by the "staff alert email" helper, which allows the admin to specify who should receive email notification of inquiries handled by this recipe. If email notification is not needed for inquiries of this type, the admin can choose None as the setting.

• Post Inquiry In

  This is a field that the admin can use to specify a tag where inquiries handled by this recipe should be posted. (This can be handled by the Choose Tags modal dialog.) If inquiries of this type should not be posted in the forums, the admin can leave this blank.

• Save

  This is a button that is used to submit the edited content of the recipe to the server.

---

Depending on how the recipe is set up, inquiries can be delivered via email, or posted in the forum, or both. The email subject line (and/or thread title) would be created automatically as follows:

• {Type of Inquiry} inquiry from {Your Name | Username}

The email body (and/or initial post content) would contain the following information:

• A message stating that an inquiry has been submitted via the contact page
• The contents of any fields (except Password and reCAPTCHA) required by the recipe
• The detailed inquiry message that the user entered in the text box

Of course, the extension will have checked the info (Username, Account Email, and Password) supplied by the user before sending or posting the inquiry. If one or more of these items don't check out, the extension can either refuse to handle the inquiry, or note any anomalies in the introductory message. This is one area that needs to be discussed.

This is just rough outline of how I envision this extension working. All comments and ideas are welcome!

[kulga]

This was a complaint I got for users who couldn't register.
Temporarily, this was solved uses the Pages extension and having contact information

[franzliedke]

As always, thanks for taking the time to come up with such a detailed writeup, @dcsjapan. :)

However, in this case I think your suggestion contains so many details that it's hard to actually turn this into something actionable.

So let's find that minimum viable product...
Since you're saying we might make good use of something like this on flarum.org, which part are you thinking of?

[dcsjapan]

This was a complaint I got for users who couldn't register.

@kulga I hadn't even considered the possibility that a user might not be able to create an account in the first place. That's a _good_ reason to make the contact page available to unauthenticated users. If there's something preventing people from registering, you'd certainly want to know about it!

So let's find that minimum viable product...

@franzliedke I tried to suggest an extension that would be as flexible as possible, on the assumption that the result would be something that everyone can use. We could try to pare it down to the bare essentials, but I fear that the closer we get to something that will perfectly suit the needs of the Flarum community, the less likely it will be that someone else will want to use it ... so it becomes harder to justify the effort.

Ultimately, all we really need to do is give users who can't post or register some way to contact the staff. At present, the closest thing we have to that is the "Contact" link in the footer of the flarum.org site. There are two problems with that:

• You have to leave the community site to find it.
• It's a link to Toby's email, which isn't optimal for forum support.

We really ought to offer a contact link somewhere on the community site ... one that will provide output accessible to the entire forum staff ... or to more than just one admin, at the very least.

The workaround described by @kulga might be the easiest way to get there: use the Pages extension to create a place for the contact link. This could be a link to a "Flarum Community" Twitter account that we could all keep our eyes on ... but that has the downside of being public. Or it could be a simple form that uses CGI to output to a mailing list, sort of thing.

If that sort of workaround won't be sufficient, and we really want an extension for this, then the obvious move would be to eliminate some of the configurability from my proposal. Before we do that, however, we should probably put our heads together and figure out:

1. What inquiry types we want the contact page to be able to handle, and
2. What information we need to solicit to handle those inquiries efficiently.

In that event, we should probably put this issue on a back burner and discuss this elsewhere first.

[franzliedke]

Another option might be to bake this into the Private Messages extension... that would give us an interface for reading the messages that would not necessarily require email.

For busy sites, I personally would not want a form that basically allows anyone sending me emails.

[dcsjapan]

Another option might be to bake this into the Private Messages extension... that would give us an interface for reading the messages that would not necessarily require email.

I like the idea of setting a private conversation as the output destination. I added Post Inquiry In because I didn't really like the idea of email being the only output option. But making it possible to output inquiries would mean admins must be very careful to avoid posting private information in an area that's readable by the forum membership at large ... not to speak of the entire internet.

Using private convos as the output destination would be a bit safer on the whole. And if there will be a mechanism enabling automatic email notification of new private conversations (which is a no-brainer) then we don't really need email output either. So it would probably be best to revisit this topic once we know what the private conversation functionality is going to look like.

For busy sites, I personally would not want a form that basically allows anyone sending me emails.

I'm with you there. 😀

[johnhearfield]

A bit like a ticket system, when the user sets up an enquiry, its categorised and is assigned a ticket id or similar. The tickets can then be moderated accordingly, and accessed in the /admin dashboard?
Or you could have a /support route?

Only brainfarting here, but I see where your coming from

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!

[stale[bot]]

We are closing this issue as it seems to have grown stale. If you still encounter this problem with the latest version, feel free to re-open it.