Just to update this ticket:
Looks like the MobileFront end team have been poking this area not too long ago: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/482233
Thu, Apr 18
This is the desired status based on the statement I've got from Product Management.
I just wanted to check we have a common understanding of what adding these languages "to the list of language codes supported for Lexemes." means:
You can see on beta that the merged patch means e.g. rm-surmiran can be used as a code for: lemmas, forms and glosses.
Wed, Apr 17
From the screenshot and my testing looks like the request is blocked by CORS and then the the response is blocked by CORB.
1 line fix at https://github.com/wmde/wikibase-docker/pull/80
Tue, Apr 16
https://gerrit.wikimedia.org/r/c/wikibase/termbox/+/504240 shows that perhaps a way towards solving the bug is trying to delay the removeAlias action (and thus the reactive update) until after the focus has happened.
Mon, Apr 15
Adding to camp since I guess fixing is in this realm
Fri, Apr 12
Thu, Apr 11
Wed, Apr 10
I took the "blue" from the mocks (#36c) and I assumed it was supposed to reflect accent50.
@Hanna_Petruschat_WMDE is that right?
So, my suggested approach to this is:
- have a mixin that:
- creates a data field focusIn
- has 2 methods that change that field true/false
- mix this mixin into LabelEdit and DescriptionEdit
- wire up @focusIn and @focusOut to the mixin methods
- optionally add wb-ui-focus-in-input class to TermTextField based on focusIn field value
- add new focussedTermInput scss mixin with blue border
- add scss mixin to wb-ui-focus-in-input
Tue, Apr 9
This appears to be solved by the fix for https://phabricator.wikimedia.org/T220379#5097045 :)
@Pablo-WMDE @Jakob_WMDE I heard on IRC that you found performance problems with using spread and replace on the entity mutations. Is that the case? If so I guess we need to use Vue.set but otherwise I think we might want to use spread for consistency, readability lack of dark-arts etc..
Moving back to To Do because it looks like debugging is probably going to need some thought about: T220375 first to be effective. Also want to merge the results of T220379 just in case there is some connection.
In attempting to debug this I built the development version with docker-compose run -e NODE_ENV=development --rm node ./node_modules/.bin/vue-cli-service build
Mon, Apr 8
I don't know loads about this but I wanted to ask if this need could be met by our existing support with -x-. E.g. could you use rm-x-Q688873 for rm-rumgr?
Just to help with reviewing: as part of this task we had to make sure that people won't leak their IP addresses; this can be "product tested" as follows:
In order to give this a product test you could try something like the following:
- log into beta wikidata
- open a page with the new term box
- duplicate the tab
- in one tab log out
- in the other tab enter edit mode
- make an edit and click save
- check that there is now no edit in that entity's history
In our "storytime" type slot I think we said the following.
I tried manually editing the test Dockerfile generated by blubber to run npm ci rather than`npm install`. I was thinking that this might then result in a test failure but this was not the case.
Thu, Apr 4
Looks probably fixed. Waiting to see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/500856 go in as a confirmation
Thanks for finding and fixing this.
Tue, Apr 2
Mon, Apr 1
My suggested thoughts on implementing this:
- Add username to the USER store module
- Add actions and mutations for setting username in store
- set username
I'm taking a look at this from the WMDE side. Thanks both of you for digging into this.
Fri, Mar 29
also IMHO this is not an extra story or anything. This is just part of implementing the save request
I think we do.
Thu, Mar 28
Wed, Mar 27
From Mattermost: according to @Addshore WikiPageEntityStore is the place to look for hints as to the existing logic
I took a little look at this and I'm not feeling super clear on what the acceptance criteria are. My immediate thoughts would be that baseRevId not equalling the latest id shouldn't immediately result in a conflict.
Tue, Mar 26
Mar 22 2019
Mar 21 2019
Mar 20 2019
This seems to me to be done in wikibase/termbox but we are still waiting on updating the pin. This is blocked by diffusion / gerrit sadness. See: T218780
You can see an example of this story working at: https://wikidata.beta.wmflabs.org/w/index.php?title=Q515700&oldid=1101978&useformat=mobile
In the daily today we talked about:
wbeditentity for saving and will not generate custom edit summaries. This will result in generic "Changed an Item" summaries for every save.