Note to self:

cd bin

bookmark_email_extractor.pl -f [sender] -t "IMPORT_[DATESTRING][incrementor]fromemail TAGME" curseq:+100 | php -f bookmarkconverter_manual_to_FF.php > import_[DATESTRING]fromemail_[batch]_phone.html

Example (most recent used):

bookmark_email_extractor.pl -f phone -t "IMPORT_20220724006_fromemail TAGME" curseq:+100 | php -f bookmark_converter_manual_to_FF.php > import_2022_07_24_from_email_300_phone.html

Start with the first 100 msgs of the present curseq in the bookmarks folder. You can reassign the problem entries to sequence importskip.

Note! You will have to manually pull out any with commentary, and manually cut-and-paste in the commentary to the web interface. Infuriatingly, there doesn't seem to be any place in the import format for it. (But! Anything after an entry's closing A tag is conveniently ignored.

Also, maybe find out why that "quoted-printable" bug happens, and fix the truncated (or rather, not re-appended) subject lines bug.

Testing, 1 2 3 testing.

Muninn now has a web interface for managing contacts, whoo!

Still coyote ugly, but functional.

As per previously, I've changed the structure of the msgs table to support the reality that contacts' phone numbers change, and that the relationship between the msgs and contacts TABLES can't be dynamic or future changes to phone numbers orphan msgs in the log.

Now that I have FIELDs fromcontactname and tocontactname in TABLE msgs, I don't need VIEW v_msgs_2 to hit TABLE contacts, as per below.

I am about to eviscerate it, so I'd like to store this wonder for posterity:

CREATE VIEW `v_msgs_2` AS
SELECT
       `msgs`.`id` AS `id`,
       `msgs`.`body` AS `body`,
       `msgs`.`created_on` AS `created_on`,
       (CASE
             WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN 'from'
             WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN 'to'
             ELSE NULL
             END
             ) AS `tf`,
       (CASE

                WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN `msgs`.`fromnum`
                WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN `msgs`.`tonum`
                ELSE NULL
                END
                ) AS `num`,
       (CASE
                WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN `cf`.`name`
                WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN `ct`.`name`
                ELSE NULL
                END
                ) AS `name`
FROM (
        (`msgs` left join `contacts` `cf` on
                (
                     (`msgs`.`fromnum` = `cf`.`number`)
                )
        ) left join `contacts` `ct` on
               (
                        (`msgs`.`tonum` = `ct`.`number`)
                )
        )
ORDER BY
      `msgs`.`created_on`,
      `msgs`.`id`

The new improved view is:

CREATE VIEW `v_msgs_2` AS
SELECT
       `msgs`.`id` AS `id`,
       `msgs`.`body` AS `body`,
       `msgs`.`created_on` AS `created_on`,
       (CASE
             WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN 'from'
             WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN 'to'
             ELSE NULL
             END
             ) AS `tf`,
       (CASE

                WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN `msgs`.`fromnum`
                WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN `msgs`.`tonum`
                ELSE NULL
                END
                ) AS `num`,
       (CASE
                WHEN (`msgs`.`tonum` = '+1617XXXXXXX') THEN `msgs`.`fromcontactname`
                WHEN (`msgs`.`fromnum` = '+1617XXXXXXX') THEN `msgs`.`tocontactname`
                ELSE NULL
                END
                ) AS `name`
FROM msgs
ORDER BY
      `msgs`.`created_on`,
      `msgs`.`id`

Works great.

Next: update the view name and corresponding PHP call. ETA: done!

Note to self: the original dev space is pointed at the dev db. There is now a fresh install of everything (except send_notifications), including a new db, at the shiny new subdomain on sere with SSL and authentication and everything. Ooooh. So responsible.

(Not everything; self, feel free to get around to implementing Twilio's authentication check thingy.)

We're still waiting on ssh access to sere.

Timezone seems correct?

To do:
Check to see if the helper library uses HTTPS.
Implement sending from sere.
How about those "reply" links.
Paging.
Styling for:
- attractiveness
- readability (alternating lines?)
Populate the contacts table
Decide what to do about forwarding to cell phone
- enabling replies?
- enabling initiating from cell?

So I just figured out the business model of services like easycron.com. The name threw me for a loop, in that, (1) their interface isn't significantly easier than just doing the old crontab -e thing for yourself; (2) and to the extent it is, you can just use a free online crontab generator and cut-n-paste; and (3) they charge money for something that is basically already free.

I had hypothesized that it serves people who want cron but aren't allowed to have it by their, say, shared web hosting hosts. Maybe that's a thing? My shared web hosting hosts have cpanel, and for as long as I've been with them (which isn't too terribly long, just a few years) they've had the cpanel interface to cron. Honestly, I would think most people who know how to spell cron would have access to it. (I say this as someone who has, an entirely embarassingly number of times, typed man chron at a prompt.)

But I've figured it out. The problem in my perspective is that I hadn't previously actually tried to use cron for anything actually important on a shared device, like a business purpose.

Vanilla-flavored cron -- there are allegely more enlightened varieties, but not on Debian -- interprets all times expressed in crontabs in whatever the timezone of the server is. Period.

There's a bunch of hacks you can do if you're running the server personally, but if you don't have root or otherwise aren't in a position to configure the whole machine, you're mostly out of luck, unless you want to run an every-minute cronjob which just fires off a smarter program that does your actual cronjobs.

Or you can use easycron.com, which lets you set the timezone of your jobs.

Seriously, apparently their business model is to some substantial extent leveraging the fact that Javier Fernndez-Sanguino Pea refuses to implement timezone sensitivity in Debian's cron. And whomever else is refusing to implement tz sensitivity into their distro's crons.

Now I'm looking into at.

1

The tao that can be tar(1)ed
is not the entire Tao.
The PATH that can be specified
is not the full PATH.

We declare the names
of all variables and functions.
Yet the Tao has no type specifier.

Dynamically binding, you realize the magic.
Statically binding, you see only the hierarchy.

Yet magic and hierarchy
arise from the same source,
and this source has a null pointer.

Reference the NULL within NULL,
it is the gateway to all wizardry.

( Read more... )