Re: BUG #15706: Support Services page out of date - Mailing list pgsql-www
From | Magnus Hagander |
---|---|
Subject | Re: BUG #15706: Support Services page out of date |
Date | |
Msg-id | CABUevEzL8a8TMnsyxiDOgmt9n6ZecRN=A_gqD7fGiQCKfjgOTg@mail.gmail.com Whole thread Raw |
In response to | Re: BUG #15706: Support Services page out of date ("Jonathan S. Katz" <jkatz@postgresql.org>) |
Responses |
Re: BUG #15706: Support Services page out of date
|
List | pgsql-www |
On Sat, Apr 27, 2019 at 5:48 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 3/25/19 5:33 AM, Daniel Gustafsson wrote:
> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net>
> wrote:
>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org
>> <mailto:jkatz@postgresql.org>> wrote:
>>
>> Some of the pgweb folks have discussed doing that before; it's not
>> a bad
>> idea, and perhaps would cut down on some of the headaches.
>>
>>
>> That was in fact the original plan, nobody just got around to building
>> it. There was even a db field for it in the early dev snapshots, but
>> it was removed since it was never quite done.
>>
>> The general idea was to just have a "last confirmed" timestamp field
>> on each entry, and just stop showing any entries that have not been
>> confirmed in <n> days/weeks/months/whatever. We can keep them around
>> some extra time beyond that in case people come back to update them
>> later of course.
>
> I think it makes sense to remove after a set timeout, if the user hasn't
> verified in 3 months (or some
> other sufficiently long period) then the odds that the entry is out of
> date seems quite high.
>
>> Oh, and +1 for doing the same for products.
>
> +1
So I had (made?) a chunk of uninterrupted time and went ahead and did a
manual scrub of the professional services page with a test for the
proposed above algorithm. Summary and details to follow:
Thanks! That must've been a painful couple of hours :)
<snip>
This is also a long way of saying that I think we should proceed with
the solution to help automate this. After going through the painstaking
process again, I'd recommend it works kind of like this:
- An email goes out once every {6 months, 1 year} to the organizational
contact that says something like: "Hi, This is an automated check to
ensure your company is still an active PostgreSQL service provider.
Please click the URL provided to confirm. <UniqueURL> If you do not
confirm within 7 days, your listing will be unpublished"
7 days might be a bit on the short side. If someone is unlucky they get the notification while on vacation for example, and then they're delisted before they can even see it.
- If user clicks URL, it is confirmed and the last_confirmed_date is set
to CURRENT_DATE
- If user does not click URL, we set the entry to unpublished. This
would put it into the moderator feed, and one of the pgweb moderators
can then take further action if need be.
That's pretty close to my original thoughts around that, except I'd just delete them as step 3 and not bother the queue. I'm fine with de-listing it as well, as long as pgweb moderators are happy to handle that :) That would also take care of the scenario where the email bounces, by simply being able to ignore that fact and leave it up to the individual moderator to handle manually.
Anyway, products needs a scrub as well, which I will try to block out
some time for in the coming days to handle those as well. Those should
hopefully not take as much time as they are a bit easier to verify.