pipelines fixed, thanks @prabhat, and is now deployed. closing.

Code added => merge_requests/21
Needs review & deploy. cc @Protsack.stephan @prabhat

1. Add task items:

Dev passed. on Prod; tested; fixed .env var; deployed; tested. We're all good!

on dev. testing.

Will do; I pushed a small branch MR this morning; should be good to go to finalize testing on dev and will move ticket accordingly for prod.

@JArguello-WMF done, w/ formatting

@JArguello-WMF done, w/ formatting

@JArguello-WMF updated this one too, similar to others.

@JArguello-WMF done

@JArguello-WMF done

Update - new deprecation time == End of Jan 24.
Priority == high

Priority == medium

Priority == high but not critical
Difficulty == easy

Priority == low but a good to have for user experience.

While we still probably want the ability to fire an event when a user makes their first request - this ticket is very old now and the environment has changed. Closing as we’re tracking app events in other tickets now.

docs code example fixed and deployed.

Dev looks good now w/ same article && section

...dupe ticket of this => https://phabricator.wikimedia.org/T351592

so yes, this API looks what I am looking for in regards to functionality.

Can we first address this:
Is the On-Demand API (docs link I gave prior) what you're looking for in regards to functionality?
It grabs the current version of a single article. That is what you're asking for yes?

The On-demand API offers single article response, instead of going through an entire project dump => https://enterprise.wikimedia.com/docs/on-demand/

@JArguello-WMF It's security and marketing related. Anything public facing that's not 'public' or that we don't want to rank in search engines and take away any keyword/keyphrase from our site and marketing efforts should either be password protected, or at an absolute minimum have noindex/noarchive meta robots tags to tell search engines to not index it.
The "shouldn't be running betas on prod domain subs" is we shouldn't be adding aforementioned non-public pages/tools/content to *.enterprise.wikimedia.com.

yeah the ID is just that, non-incremental. count is something we'd need to add to the API. I agree it's a nice addition.

has now been deployed to Prod. confirmed working as of this morning.

Found "enterprise" referenced in HF too but it's the free dumps https://huggingface.co/datasets/SaulLu/wikipedia_html_enterprise

In T343326#9168630, @JArguello-WMF wrote:

@creynolds has been asking.

👀

Errors in site editor:

We have date_created field now for some time. @JArguello-WMF review ticket pls

API consumers can use is_breaking_news field in Realtime API in production

Note that it's version.is_breaking_news

Dev has run course (manually x each step) and deployed good now.

In this case, I believe we don't currently have a way to know when that happens in order to fire an event... that technically would be the ticket and the event delivery endpoint is probably changing soon; offline convo; standby.

in debug found that manual plugin dir upload wasn't overwriting previous and file vars weren't in sync between plugins. closing as solved.

This one it seems: https://phabricator.wikimedia.org/T329496

@Alexander.lauie understood. ty

@Alexander.lauie that's fair and noted.

This will solve a current issue however we need to discuss user pool/group being directed tied to feature access, as most use cases will fit that case, however we're already at a point where sales is more dynamic than that.
At some point APIs/features and Support tiers/features would be options assigned to a user account as opposed to a user group assigning those. Just a different approach from init.

Context for reference.

• @HShaikh for DNS / IT specific help
• Amy Mueller for ZenDesk admin specific help

fixed. ty

Fixed. ty

installing the plugins manually right now

by "manually" you mean from the WP plugin repo via wp-admin and not the WME-repo held custom plugins right?

@Alexander.lauie think that's an issue in the lambda func sendCodeForgotPassword()?

For reference I just had AlexL add a single resp == "Input must not include spaces".
I'm also looking into sanitization philosophy outside of this ticket's intent.

@Alexander.lauie I thought what @Anna.bondar had in the email template was good. We should state their username clearly like that as it isn't inherently understood that the "HI {blah}" is their username to log in with... also don't need to target blank in anchor tag inside emails.

fixed, deployed to dev for Q/A, @Anna.bondar

MR added for @Alexander.lauie

Confirmed - thank you sir.