[Wikidata-bugs] [Maniphest] [Commented On] T224833: first client edit for simple typo

[Esc3300]

Esc3300 added a comment.


  A problem we had with the Russian gadget is that people try to "update" 
information from the client instead of adding a new statement, e.g. change 2019 
to 18 June 2019. In general, this isn't much of an issue for this type of edit 
except when the statement on Wikidata includes a reference stating "2019" and 
not "18 June 2019". Even a typo could be something that requires a new 
statement.

TASK DETAIL
  https://phabricator.wikimedia.org/T224833

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Esc3300
Cc: Esc3300, Addshore, Charlie_WMDE, Incabell, Aklapper, Lydia_Pintscher, 
darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
_jensen, rosalieper, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T224833: first client edit for simple typo

[Lydia_Pintscher]

Lydia_Pintscher added a comment.


  In T224833#5250530 , 
@Addshore wrote:
  
  > Sorry for the wall of text comment, some of these things are probably only 
relevant further down the line, but I might as well write these down now so we 
can refer back to this comment.
  
  
  Thanks :)
  
  > Some questions from my side, though perhaps these are going to be left for 
later? (I guess they all need answers before deployment):
  > 
  > - If the user on the client is blocked on the client, should they be able 
to make this edit? / should the edit link even appear?
  > - If the client user is blocked on the repo, should they be able to make 
this edit? / should the edit link even appear?
  > - If the client wikipage is protected, should the edit link appear?
  > - I guess if the repo entity is protected, then the edit link on the client 
perhaps should not appear?
  > - Should this edit link appear for anon users on the client?
  > - Should the users presented this edit option have some sort of user rights 
already?
  > - The data edited for wikidata will have a different license to the ones 
users have agreed to on the client, how will this license difference be exposed 
while editing?
  > - Do we want edit conflict detection here?
  
  Yeah we need to address all of those but I intentionally left all of that out 
of this ticket because people were already saying that it is way too big as is 
;-)
  I have a list of things to address that overlaps with yours. I'll add your 
points to that and then they'll go into new tickets later.
  
  >> make an edit for a simple value from a client page
  > 
  > What are we defining as "simple value" here?
  >  All values have some sort of validation, well parsing and then formatting 
is always part of the flow for values.
  >  I guess "simple value" here means values that are currently edited on 
wikidata with no possible magical JS UI?
  >  So perhaps:
  > 
  > - String
  > - External ID
  > - URL
  
  Yeah simple in this case means no suggesters, experts etc. So that boils down 
to the 3 you listed. I didn't take external ID because that has link formatting 
but I guess that would also still be ok.
  
  >> No forced page reload after the edit is necessary yet
  > 
  > Does this mean after clicking save we want the value edited on the page to 
be updated?
  
  No to keep this super simple we just make the edit to Wikidata and then the 
user has to reload the page to see the actual effect. (Yes shitty but since 
this state will not hit production that's ok as a step.)
  
  > How about if the value being edited is used in multiple different places on 
the page?
  
  See above.
  
  > What do we want to happen if the user clicks save and then refreshes? I 
guess we want them to still see their edit.
  
  Not sure what you mean here.
  
  > This will probably mean once the wikidata edit has been made, force the 
parsercache rejection / reparse and not rely on the dispatch mechanism which 
could take a minute or so.
  
  Yeah we will have to see how that behaves later. For this ticket it's 
basically whatever :D

TASK DETAIL
  https://phabricator.wikimedia.org/T224833

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Addshore, Charlie_WMDE, Incabell, Aklapper, Lydia_Pintscher, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T224833: first client edit for simple typo

[Addshore]

Addshore added a comment.


  Sorry for the wall of text comment, some of these things are probably only 
relevant further down the line, but I might as well write these down now so we 
can refer back to this comment.
  
  Some questions from my side, though perhaps these are going to be left for 
later? (I guess they all need answers before deployment):
  
  - If the user on the client is blocked on the client, should they be able to 
make this edit? / should the edit link even appear?
  - If the client user is blocked on the repo, should they be able to make this 
edit? / should the edit link even appear?
  - If the client wikipage is protected, should the edit link appear?
  - I guess if the repo entity is protected, then the edit link on the client 
perhaps should not appear?
  - Should this edit link appear for anon users on the client?
  - Should the users presented this edit option have some sort of user rights 
already?
  - The data edited for wikidata will have a different license to the ones 
users have agreed to on the client, how will this license difference be exposed 
while editing?
  - Do we want edit conflict detection here?
  
  > make an edit for a simple value from a client page
  
  What are we defining as "simple value" here?
  All values have some sort of validation, well parsing and then formatting is 
always part of the flow for values.
  I guess "simple value" here means values that are currently edited on 
wikidata with no possible magical JS UI?
  So perhaps:
  
  - String
  - External ID
  - URL
  
  > No forced page reload after the edit is necessary yet
  
  Does this mean after clicking save we want the value edited on the page to be 
updated?
  How about if the value being edited is used in multiple different places on 
the page?
  What do we want to happen if the user clicks save and then refreshes? I guess 
we want them to still see their edit.
  This will probably mean once the wikidata edit has been made, force the 
parsercache rejection / reparse and not rely on the dispatch mechanism which 
could take a minute or so.

TASK DETAIL
  https://phabricator.wikimedia.org/T224833

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Charlie_WMDE, Incabell, Aklapper, Lydia_Pintscher, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs