Jun 13 2019
still an issue post-dockerization
This is still an outstanding task post-dockerization
This was closed when we moved to docker.
Jan 10 2019
I haven't paid to much attention to this until looking at @AVasanth_WMF 's excellent mockup this morning.
From a spaminess perspective, I'd recommend that we not have a public/anonymous form that sends email.
Jan 8 2019
This has been resolved. It turns out that our underlying email infrastructure changed, but we weren't aware of it. All withheld emails should now be delivered.
Jan 3 2019
fix merged into master
So, while fixing this problem in a branch, I encountered/reproduced the originally reported issue. The scripts that directly use a virtualenv do in fact have the user check thanks to the virualenv_activate script. Some of the wrapper scripts that compose those into useful workflows don't because the test for the "right thing" needs to be a little more complicated.
This is a super simple fix. I'll get it pushed right in.
Dec 4 2018
hotfix in place. verified that things are happy.
pushed hotfix in git. Will get it to live site asap
Oct 31 2018
Yep, we definitely need nfs, that's where we keep a month's worth of nightly backups, which we've occasionally used to roll back a bad data migration or just as a place to keep our state when we throw away a vm and provision a new one.
Oct 19 2018
I'm planning on separating the different bits of our platform into containers running on a small kubernetes cluster, and running the database as a vm outside the cluster. We haven't determined the best way to configure persistent storage (e.g. user uploaded attachments). If we can use a project-wide nfs export (which we only use for backups in twl) that's great. If that's a performance/workload nonstarter, then I'm open to guidance, including just running a container that provides storage, which backs itself up to a project nfs export.
Aug 1 2018
This is done
Jul 19 2018
A few thoughts:
I'm not even sure if we should fix this, since blocking comments is one of the design goals of this addon. @Xover might be interested to know that the makers of 1blocker have also released 1blocker x, which appears to be designed to address this concern for their users.
Jul 17 2018
Yeah, it's because the username is part of a larger block of text that's marked for translation.
Jul 13 2018
The tags were running over the bullets because the bullets weren't in the right place. The background-position css attribute must be explicitly set for CSS janus to modify the position of those images. Default is top left. That issue is now fixed in the dev branch.
Okay, I've got the issue with the empty values resolved so that we're defaulting to English when there's no suitable translation. The biggest issue I now see is that our pipe delimited tag list is running into the blue tag bullet when there are a lot of tags. Working on it.
@Samwalton9 In a dev branch, I've added the partial Arabic translation and fixed up numerous issues that were apparent to me both on the RTL rendering side and the translatewiki "add languages from the translation files" side. I can see that we have the additional issue if we're missing a translation for tags or descriptions, we're not displaying anything, rather than defaulting to the English version.
Jul 11 2018
The fix for number 1 has been pushed to master, along with a fix related to number 2. In this case, we really needed to be testing the management command that creates the reminder email signal, as that's where the problem was. Let's keep this open until we see reminder emails coming down the wire.
Jul 6 2018
I've deployed the fix for item #3.
Jun 29 2018
@Samwalton9 These emails are still scheduled. There are 3 issues that together caused them to stop working without our knowledge.
- I've modified the ListApplicationsView in such a way that the reminder email template no longer works.
- As we've previously identified, we have inadequate test coverage for emails, so the new builds didn't start failing after the change.
- We're not alerting on failed cron tasks, so the system didn't tell us that it wasn't successfully completing its housekeeping as designed.
May 2 2018
looks like I could be doing this more efficiently:
just keep me posted, as it's quite time consuming to reformulate the inserts from a dump into non-destructive updates. Let's try to get any other missing data identified so that we can catch it in one pass.
Apr 30 2018
Issue resolved. there was a new CSRF setting that didn't come into play in local dev and travis because of the lack of SSL there.
It's looking like it related to the fact that we're behind a proxy for the labs infrastructure. The issue doesn't happen in local dev, but it's there for prod and staging. I've verified that csrf is working correctly for non-admin forms.
Apr 16 2018
This change has been pushed to master, and should get picked up at tomorrow's scheduled update.
I suppose we should mark this as closed since I have resolved all related display issues I could produce on iOS. I haven't heard back from the reporting editor, though.
Apr 5 2018
1st cut of the app code is complete. I'm in the process of extending the test suite to accommodate the way the code works now. Right now the test suite creates partners and coordinators in unrelated way. I'll need to designate coordinator/partner relationships in the test suite so that I can separately test the cases of display for a coordinator that should or shouldn't have access to a given bit of content.
In addition to our recent css updates, I added a 400 error template, as that was the most interesting situation I was able to create while trying to break discussions. I tested on a recently acquired iphone and application discussions seem to work as expected. Awaiting feedback from the user that reported the issue.
Apr 3 2018
Yeah, we could probably be using requests a little smarter. It returns the status code of the logged http object...which means that you get a 404 when clicking on a 404 request object. We've got some context on that buried in closed phab task somewhere.
Mar 6 2018
I'm currently evaluating using a report builder of some kind to meet this and similar needs.
Feb 14 2018
Cause of null data resolved, but the user edit counts won't get updated until the impacted users login again. As @Samwalton9 suggested, it was an encoding issue: the input data fed into the user import code as well as the test code are already utf-8. The OAuth data coming back from live wikimedia was being treated as ANSI. Changes pushed to production.
Identified issues in both plaintext and html mime types. On the html side, there was no markup whatsoever. On the plaintext side, the options on the jinja text block were filtering out newline characters, along with other characters. Addressed these issues and deleted an unused/duplicate email template. Changes pushed to production.
Feb 5 2018
There are couple of aspects to this. None is a null value explicitly different from 0. Because we're trying our best to pull in data via a couple of different interfaces that don't always give us data, we'll never live in a world where we don't see that sometimes. We should probably make that None more informative. Basically, apps shouldn't be declined due to a null value in the system, instead the coordinator should check the link right next to that value that will often show a correct edit count. I'll also work on figuring out why we don't have data for those folks specifically.
Jan 29 2018
I've slightly updated the message template and pushed the code to production. I also fired off the task manually since it's Monday. As a sidenote, admins can view the emails we've sent under the "messages" section of the administration page.
Jan 28 2018
@Nikkimaria Yep, I'll get things pushed to the master branch this evening or early tomorrow morning. Go ahead an undo the change. Sorry for the confusion on this, all.
Jan 27 2018
Jan 26 2018
Jan 25 2018
I have everything pretty well wired up in my feature branch. Current email looks like:
Jan 22 2018
Quick update on this. Completed bits:
Jan 8 2018
I've got the model and templates wired up to Twila's bundle banner flag in her dev branch.
For the model issue, it sounds like we'll pull the descriptions and related fields out of the database and stick them either into templates or into a separate repo. Basically, get those things into code.
Nov 15 2017
Quick update: I've got a solid start on reading the ltr css into css janus, and flipping the css. I'm a nodejs novice, so I'll need to fiddle with it a bit to direct the output to programmatically named files that can then be referenced by the django bidi machinery.
Nov 14 2017
async email config pushed to prod. Testing turned up a few more cases where there the user salutation ended up being the numerical ID T169525. It was down to the fact that we're using a separate system for app comments than for the rest of the things that generate emails. That's now been resolved as well.
Nov 13 2017
Quick update: I'm currently testing using an async djmail backend for sending mail. Currently, it offers all of the hoped for performance benefits of an async mail queue, minus the capability to actually transfer any email messages. In other words, I'm making progress, but I still have a little work to do.
Nov 9 2017
I verified that this is fixed on the live site. You can check by filtering pending applications on CUP, which is waitlisted.
Nov 8 2017
Fix has been pushed to master. Should get picked up on live site in less than 24 hours.
Nov 6 2017
Nov 3 2017
Made login button an inline element. Now text overflow pushes the box out properly.
Django has some decent email testing tools that we should probably be using. DJmail, which is our current mail handling library, has some asynchronous options that don't have external dependencies, but I'll need to get at least some basic email testing in place before we can reconfigure it.
Nov 1 2017
official request submitted to translatewiki.
Oct 31 2017
This issue should be resolved, though the implementation looks a little different than what I had originally envisioned. I made the following changes:
- added a user field for language preference
- added a hook on update_from_wikipedia to set that field to the current browser language if it's empty
- re-implemented the django i18n form to also set that field for a user if they are logged in
- added the value of that field to the context loaded into all of the email templates
Oct 30 2017
Oct 24 2017
The necessary changes have been merged into master. You can see the changes here. Of course, the translations themselves will need to be done as well.
Oct 22 2017
Since the test suite has received a significant upgrade that is allowing us to move forward, I think we can either mark this one as closed and create a new task for more test suite enhancements, or lower the priority.
Oct 19 2017
I finally managed to reproduce this issue in another environment and resolve it. There were several issues contributing to this problem. There was a missing email template, and separate worker and proxy timeouts due to our current email strategy. All this was made more difficult to troubleshoot due to the differences in email configuration between production and non-production environments (we only really want to send email from prod), and the configuration of the test suite in different environments.
This was actually generated by me mistakenly. While troubleshooting T173990, I mistakenly set newspapers.com to waitlisted instead of Newspaperarchive. I almost immediately changed it back, so I'm sure when you went to go check it, you found that it was in the expected state.
Oct 13 2017
Freshly deployed production does the same thing. At this point there are only a very small number of differences in code execution between vagrant and production. This outcome tells me that's where I need to look, even though the two don't appear related at first glance.
Oct 12 2017
So, I'm unable to reproduce this issue anywhere besides production, using the same code checkout and the same data. I spent some time working on some of these individual issues, but the big question is why we're seeing them only in production. I'm going to redeploy the production server tomorrow, to see if that resolves the issue.
Oct 11 2017
The updated code has been deployed, but the issue isn't resolved. Some of the automated tests that are passing without issue in dev and staging are failing out in production. This is ... interesting. I'm going to pull down a fresh dump of the production db and see if I can reproduce the issue in another environment. At least we have the tooling in place now to ferret out things kinds of issues.
Oct 9 2017
I believe I have this issue resolved in the codebase, but there have been a lot of changes to the puppet module to support the testing improvements, so there are some steps I need to take to make sure deploying all of the changes together won't break the production system.
Sep 13 2017
I think we determined this was noscript-specific, in which case it's fine for it to be broken.
Sep 5 2017
So this turned out to be a bit of a goose chase
Sep 3 2017
I've identified that the root cause of this and several other recent showstopping bugs is inadequate testing. I realized that the existing unit tests became inadequate after I wrapped a large portion of the views with login_required; the current tests don't run any of the middleware that would give them the context required to turn up the kind of problems we're encountering. I'm moving a large portion of our tests from factory-based unit tests to client-based integration tests.
Sep 2 2017
deployed a second pass to live site. I believe this should cover all remaining reported login issues, but we can hold this issue open to get reports back in
Aug 27 2017
I've got a first pass at a fix deployed to the live site.
It looks like the issue happens when you set a partner with pending applications to waitlisted; it appears that this is related to the code that sends waitlist notifications.
Aug 25 2017
Aug 23 2017
Aug 21 2017
If the waitlisted apps aren't displayed in the current view, that's not too difficult to fix. We could add another view for that status, or add them into the pending view. That should probably happen whether we add an "any status" view or not. How we want to approach that is more of a design/ux discussion than a technical problem.
Okay, I believe I have this pretty well mitigated.
Aug 20 2017
So, I've pushed a change to staging and prod that protects us from api communication problems. It will still throw an error if the api query returns a "not found" response, and I haven't protected us against every conceivable data type problem, either.
Aug 18 2017
change pushed to staging and live site.
change pushed to staging and live site.