Lydia_Pintscher added a comment.
In T224833#5250530 <https://phabricator.wikimedia.org/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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
