New to the community? Start here

Mass changes – email example

Individual features in the Hub support email notifications. Right now changing email addresses requires going into each site, opening the application (Uptime, Reports, Security, etc), and going through settings. That’s really painful.
This request is to ensure that the new Configuration sharing mechanisms allow for fluid changes of email addresses across multiple sites.
As an example, and this is probably bad UX but it’s intended to convey the idea:
– Allow for a single common repository of email addresses for contacts.
– Create a web page that allows for the selection of one or more of these contacts via a multi-select dropdown, or a checklist.
– On that page present a grid with one row per site and one column per application.
– The cell for each site/application contains a checkbox, and on-check the selected contact(s) will be assigned to the site/application.
– The background for the cell is green when the contact has approved receipt of reports and reddish for those who have not.
– When no contact is selected, some part of the email address or contact name is set in the cell rather than the checkbox. So we can look at the grid to see what email addresses are not yet confirmed for any given function.
– On Submit of the page the approval email is sent for all changes.
– Another button is available to re-send the approval email for all unconfirmed recipients.

That’s one way to handle this.

Another way would be for an API that allows us to set the email field for a single site/application. Then we can script this anyway we want, and create our own Hub-style maintenance pages to do this and many other functions.
Another way to do this (probably preferred by WPMU DEV) would be to allow the new Configuration sharing functionality to only set whatever fields are defined in the JSON file. So we should be able to generate one or more config files that only have email-related directives, and then save these files to all sites in order to set just the fields that we want.

However this is done, note the pattern, that it is painful to make a single change across many sites. A different View of site maintenance is required. We have the first view, by Site. The next View should be by application, where we can modify a setting for multiple sites with one change to application settings.

I strongly suggest and request that the new configuration JSON files be positioned as a first type of API so that all functionality can be controlled with this one mechanism – not just email but time settings, activation status, run of manual scans, etc. You’re already doing this. Don’t require that each JSON file Must set All fields. If each JSON file is capable of setting only the fields that we want then this will be just as good as any web service API.
The problem with JSON files is that they need to be manually uploaded. If you provide a single page where one or more JSON files can be easily uploaded then this pain goes away. With the site identified in the JSON we won’t need to go to each site to load the file like we do now with configurations.
And in fact, if a web service API is implemented, we should be able to send the exact same JSON file via HTTPS. So the work you are doing now can easily be transitioned into the “Holy Grail” of an API that we need for true cross-site maintenance.
Please do not hard-code limited functionality that will require a complete re-write later, or which precludes this sort of functionality as being too expensive to re-write. Please code in a manner that will allow the modules to be repurposed – that is, the code segment that gets the email address to set the Uptime notification recipient should not be intertwined with other code. Modularize it so that a JSON file with nothing but specs for Uptime email changes can be processed, and it will work for the new Config sharing, for application-oriented maintenance as described here, And for a hopefully upcoming API.

Thanks.

Mon, 1 Mar 2021 18:14:19
  • James Farmer
    • Founder & Chair (honest)

    What you are after is a CRM :slight_smile:

    Which is quite hard lol… but not impossible one foot in front of another.

    Our new billing system is essentially a step in this direction, as it’ll allow you to list your clients and – as such – their details such as email addresses and alike, whether or not you are billing them through us.

    In terms of configs though, while there will 100% be an Uptime config facility I’m fairly sire we hadn’t really thought of it beyond:

    Toggle Email Notifications
    Threshold

    And some future additions like frequency of checks / locations etc.

    I suppose we could add respondents details (email, SMS when we implement that etc.) – which would do the trick yeh?

    • Tony G
      • Mr. LetsFixTheWorld

      As I noted in the other thread on aggregating requests, I think it’s fair to say that we want/need to be able to change all and selected fields for all and selected sites. The mechanism (file/ws) isn’t important. No matter what you implement there will always be requests for the things you didn’t implement. We know it will happen, which is why I have been trying to help head that off at a higher level.

      To be clear, Email settings was only an example, so this would not be solved with a CRM. This is about multi site management through a common Hub.

      As I said, it’s all pretty simple the way the JSON is configured now (at least for Defender) : For each config setting there is a JSON node/attribute/value. If we upload a trimmed-down JSON file that only has one field, then just that one field should be changed – we shouldn’t get a rejection that we’re missing fields that we don’t want to change.

      Similarly, if the JSON for The Hub is created the same way, and I hope/assume it is, then we should be able to use a single file to toggle the setting for one or more fields for any site.

      Ouch – that means we need to upload a dozen files to change one field for a dozen sites? Nope, not if one file is a collection of directives for multiple sites:

      {
   site: {
    id: "foo.tld",
    uptime: {
      enabled: true,
      notifylist: { "[email protected]", "[email protected]", "[email protected]" },
  },
  site: {
    id: "bar.tld",
    uptime: {
      enabled: true,
      notifylist: { "[email protected]", "[email protected]" },
   },
}

      With that format we can craft and upload our own JSON, whether through code or through new UI’s created outside of DEV just for this purpose. We can also have that file generated from other systems based on the employee roster, holiday schedule, or whomever is in rehab this week.

      DING : I see new plugins to support the WPMU DEV Hub Framework. Might that not draw some attention to the fact that this company has such a beast?

      DING DING : I see JSON files created from the CSV exported from Forminator forms where this data is user-provide. How’s THAT for synergy?

      The beauty of stuff like this is that it will cost you a lot less in development and maintenance, when solutions like this are easy and modular. C’mon bud, use the tools to make this easier on all of us, before or while this is all still in development. The current model is for the birds : let’s hard-code everything based on whatever is on the minds of the team right now, and if someone wants something different later, probably something that a lot of people want that we simply didn’t think of, we’ll consider each request and hard-code them all separately … in the next major version. We continually see here that this model always leaves DEV in a catch-up mode. There is an opportunity now to get ahead of the curve – where the code actually faciliates the creation of marketing channels. How tough is that?

      OOPS : I’m doing it again. :slight_smile: Thanks for your patience.