Worth double checking the tests here too - this should have been caught in, I think, https://github.com/WikipediaLibrary/TWLight/blob/master/TWLight/emails/tests.py#L94.

Good question - they were added way back at the start of the project and we never spent too long thinking about them. Agree they might not be that useful and could probably be removed.

This touches on something we've been discussing more broadly, that perhaps we should be having users apply to 'collections/streams' rather than resources. The behaviour for partners with one collection (i.e. most of them) would remain unchanged, but this could solve a number of issues with the behaviour around applying for collections.

This is definitely a bug, which should be avoided at https://github.com/WikipediaLibrary/TWLight/blob/3e3f2c69d3cb0442ff066b40822e119acc509ec1/TWLight/emails/tasks.py#L138.

We aren't planning to force centralisation of resource suggestions on the Library Card platform. We monitor multiple request pages (e.g. Meta and frwiki too) and the library card platform page is just another possible venue to get requests & suggestions to us.

Yeah this is a good point - we'll need to broaden the list of possible statuses for partners though. We have some 'not available' partners that have never been available because we're in the process of adding them. They should probably still be handled in the way they are now, so adding a new status for 'Closed' or similar would be best to handle the case where we've been offering applications and then those resources stop being available.

https://github.com/WikipediaLibrary/TWLight/pull/238

https://github.com/WikipediaLibrary/TWLight/pull/238

https://github.com/WikipediaLibrary/TWLight/pull/238

@Nikkimaria Do you think we need per-partner email templates for this? I imagine any generic emails would require followup to explain how to use the code?

Would T206627 solve the problem here?

This is now the tool behaviour. Filling in gaps is a separate task.

Yes please feel free to work on existing open tasks for the tool, though I think many (if not most) have now had work done on them and pull requests submitted!

This is a bug I noticed recently, it occurs when a recent change is something other than an edit or page creation. It should be fixed in https://github.com/Samwalton9/hashtags/commit/b7981bdbba54baa2da324dec68afe9affcecddde

I think an email is probably the best bet. We're already displaying a notice on the tool if collection seems to have stopped (T216727).

@gaurav7019 The first step would be setting the tool up locally and confirming that you see the same behaviour. The repo can be found at https://github.com/samwalton9/hashtags.

No, I think we need a better solution than arbitrarily restricting any tags that get too large.

In each case, 'renewal' refers to a request that an account that has expired (ended) continue to be available for more time. I don't believe the _meaning_ of the word changes between these messages:

Just to clarify - the recentchanges timestamps were logged from the recentchanges EventStream, not the database - not sure what the parity between those data sources is.

What quer(ies) are you planning to use to find the data?

Adding Data-Services in the hope that someone can provide advice :)

@Mvolz Do you already have a contact at JSTOR to help with this? If not we'd be happy to help!

Please feel free to contribute to unassigned tasks on the Hashtags workboard :)

@ParthS007 The ultimate aim here would be to set the tool up on translatewiki.net, no need for you to provide the translations yourself.

Hmm. We have the The-Wikipedia-Library channel on Freenode IRC, which could work? Otherwise, I'm not sure - I don't really have the time to invest in coordinating a chat channel for this tool right now.

All rev_ids from the last database backup from the old tool are now imported. Now working on filling in the gaps from the revision table.

That would be great @ParthS007! To help, I've enabled Travis builds for the repo (https://travis-ci.org/Samwalton9/hashtags). It would be great to have Codecov integrated there.

That's the default behaviour when containers are brought up - the app and scripts containers will exit with an error because the db container is still starting up. The healthcheck allows the app container to double check it can connect to the db (i.e. it's finished setup) before running. I'd like to keep that smooth behaviour.

Could you please tell me what is 'revision table'?

I had a hunch that I think I've confirmed - the culprit appears to be the healthcheck at https://github.com/Samwalton9/hashtags/blob/master/docker-compose.yml#L25. I'd appreciate someone else double checking, but I removed the healthcheck and app dependency from docker-compose.yml, and ran docker-compose up -d --build again. Didn't see any of these logs without the healthcheck.

In T216393#4975034, @Setian wrote:

In T216393#4975019, @Samwalton9 wrote:

2019-02-21T16:38:43.676509Z 27866 [Note] Access denied for user 'root'@'localhost' (using password: NO)

Looks to be happening every 30 seconds.

I wonder how we're going to track this down.

In T216393#4974924, @Setian wrote:

In T216393#4973559, @lalit97 wrote:

I am done with the setup and able to reproduce the same error

Can you paste the relevant excerpt from the log? Also, do you have an idea as to what is triggering this (e.g. viewing pages, editing pages, etc.)? Thanks.

Code changes are now in the repo (https://github.com/Samwalton9/hashtags/pull/8/). Still working on database updates.

Because it was something we discussed last checkin, noting that using a named ref doesn't fire a second event for links in that reference tag (desirable).

Small update - #flickr2commons is now 600,000/900,000 hashtag records in the database.

Making good progress on this at https://github.com/Samwalton9/hashtags/tree/db-rev-ids. I think the code part is done, and now I just need to import/merge the old data.

Hi @ParthS007 - yes, please feel free to take on any of the unassigned tasks on the Phab board and make PRs at the repo you linked. T216393, T216614, T216398, or T216399 might be good places to start :)

Yep, fair point - I was making notes while trying to debug. Will create a task now.

Another possible error, in addition to the two existing subtasks, that I haven't quite been able to reproduce yet:

I'm not currently sure if this is something we care about, but it is somewhat contrary to how the externallinks table/LinkSearch works, which logs every individual instance of even the same link on a page.

@bmansurov Strange. I just reproduced it at User:Samwalton9/sandbox10 (the most recent deletion logged at https://en.wikipedia.org/wiki/Special:Log?type=delete&user=&page=User%3ASamwalton9%2Fsandbox10&wpdate=&tagfilter=&subtype=).

Wow, that's some amazing progress @Green_Cardamom - thank you so much for your efforts on this!

Just noting here that Tool-Pageviews has an option to find pageviews for pages on which a Hashtag has been recorded in the tool, but the link needs updating to point to the new tool location.

This is probably somewhat more useful than wildcard hashtags.