note: I wonder how much effort this would need to automate

Ready for @dang to check error reporting and hopefully move to done!

We have now waited a few days. Seems like the errors are dying down. We saw no errors last night. We will wait until Friday to move this to done. The next step is confirming there are no more errors and move directly to done.

Works fine for me in firefox 157.0.1. Jumps to that section once the policy loads.

Review submissions are mostly being happily submitted now and the submission form had some rough edges smoothed:

• urls render to the correct wiki
• the form validation all behaves nicely etc.

Added another small pile to 1208. Need to determine why it's not playing nicely with our backend patch. Seems to throw:
[previous exception] [object] (PDOException(code: 23000): SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'wiki_id' cannot be null at /var/www/html/vendor/laravel/framework/src/Illuminate/Database/MySqlConnection.php:53

I went and confirmed that I saw no more errors since Monday! Nice! I know it took a while but this kind of cleaning and maintenance does have lots a value. Less logspam makes real issues much easier to identify.

Discovered that the styling issues relating to alignment of the tabs is pre-existing.

Above is a patch for some very initial UI work to allow us to make the precise tab of the WikiSettings addressable in the URL patch.

As I commented on the PR in the daily we had planned to discuss this with @dena later today. Seems this won't be possible.

What is this stalled on? T436530: UI: Mock Service Migration - Remaining Handlers being completed?

Just realised that the status pages wasn't properly updated. I've done that now

Running the job again (and keeping the output handy for myself locally with kubectl exec -ti deployments/api-app-backend -- php artisan job:dispatchNow App\\Jobs\\SendPolicyAnnouncementJob | tee /tmp/SendPolicyAnnouncementJob.log

Running the job with:
kubectl exec -ti deployments/api-app-backend -- php artisan job:dispatchNow App\\Jobs\\SendPolicyAnnouncementJob

deploying these two PRs to staging, running the job there and inspecting the output.

Monday; ready to go now

I'm not sure I've seen something quite like this.

I guess we need to move this forwards; this is quite a complicated bit of our stack so I don't think we should ship it on a friday afternoon. Stalled until monday.

I'm not certain of all the details but it seems like perhaps there was a decision >1 year ago to no longer use WikibasePingback at all for collecting data about 3rd party Wikibases (T399155) but I didn't find solid written evidence of this. If that's that case then an alternative to this migration is just to remove all this code if nobody is actually using it.

T408316: 📜 P1: Activate the new policies (real users are required to accept them) is now done so this can be unstalled

I'll let you double check again @Anton.Kokh

Running:

kubectl exec -it deployment/api-app-backend -- php artisan tinker --execute "
        \App\Policy::create([
            'policy_type' => 'hosting-policy',
            'content_vue_file' => 'hosting-policy/version-1.vue', 'active_from' => '2026-08-27'
        ]);
    "

Also set the newer ToU and first hosting policy active_from date to 2026-08-27 (today) rather than yesterday for consistency with Production when I update it in a moment

setting the date back for the first ToU to 2022-01-01 on staging

Anton spotted that the effective date of the first ToU should be 2022-04-11, not 2022-01-01. Everything else looks good.

I've worked my way through the checkboxes; I think everything is good. Let's see what @Anton.Kokh says

Done on staging. Now moving back to doing to confirm all the steps before handing over to the PM

Fat finger potential for this is very high; I did manage to fat finger prod not staging but undid it immediately. Probably tinker is still not a great tool for this

T434193: 📜 P1: Improve upcoming and outdated version banners on policy pages is now done so this should be unstalled

Going to mob review this with @Ollie.Shotton_WMDE and @Rosalie_WMDE

@Ollie.Shotton_WMDE and @Rosalie_WMDE and I agree that this code path is inaccessible as long as when T408316: 📜 P1: Activate the new policies (real users are required to accept them) is done we activate the new policy on the same day.

I realise this is now a year later and this ticket is still open. I hope I read the reply correctly that it is now working fine.

Seems like we did document this in a paste

My assumption for cloud is that the desired state is: 120 for items 122 for properties, 146 for lexeme *if enabled*. We do not allow users to configure this

On current versions of a policy page, there should be no upcoming or outdated version banners. This is already the case; just don't break it.