Problem/Motivation
Suggested in a UX meeting:
A simple status report message about JSON:API's access being enabled, especially when write access is enabled. This was requested by a couple UX team members who audit the site status reports for many sites.
Proposed resolution
Add status report entry, with language closely matching that at /admin/config/services/jsonapi
as added by #3039568: Add a read-only mode to JSON:API and reviewed in detail there.
Remaining tasks
Review
User interface changes
- Before
- After (with read-only mode OFF)
- After (with read-only mode ON)
API changes
None.
Data model changes
None.
Release notes snippet
None.
Comment | File | Size | Author |
---|---|---|---|
#25 | 3068275-25.patch | 1.31 KB | alexpott |
#25 | 14-25-interdiff.txt | 1.83 KB | alexpott |
#25 | read-only.png | 55.77 KB | alexpott |
#25 | crud.png | 159.32 KB | alexpott |
#24 | Screenshot 2019-10-09 at 11.24.11.png | 91.92 KB | alexpott |
Comments
Comment #2
Wim LeersIf we do #3039687: Add an API read-only mode to Drupal core, then this would need to be moved along.
Comment #3
Wim LeersComment #4
Wim LeersComment #5
shimpyThe patch is working perfectly. Thanks
Comment #6
Wim Leers@shimpy Why did you post screenshots? I already provided screenshots…
Comment #7
Gnanasampandan Velmurgan CreditAttribution: Gnanasampandan Velmurgan as a volunteer commented#3 patch
Comment #8
Wim Leers???!
Please don't mark issues
without saying anything at all, @Gnanasampandan Velmurgan.Comment #9
Gnanasampandan Velmurgan CreditAttribution: Gnanasampandan Velmurgan as a volunteer commentedSite administrators easily configured both read and all Json api operations . Also I have reviewed and tested. #3patch worked for me.
Comment #10
gabesulliceLooks good, Wim. Thanks!
Comment #11
xjmI think this is reusing text from our previous UX reviews when we were working to add the module to core. Can someone confirm? If so we don't need UX review a second time.
Comment #12
Wim LeersAlmost.
/admin/config/services/jsonapi
contains the following text:This patch is using the text:
The intent was indeed to make these strings as similar as possible.
Comment #13
alexpottOne possible UX concern for me is that unlike the field on the form you don't know if the description applies to your current setting on not. If you have it set to "Read only operations" you are not able see that the other possibility is "All operations..." but you'll set the description. I think we should only display the description if we're not in read only mode. Also I think that maybe the description probably should also contain a link to the config page where the user can change this. Otherwise the user has to navigate a tortuous route via d.o if they think "oh I'd like to change this".
Comment #14
Wim LeersGreat observations, thanks! Done. ✅
Comment #15
gabesulliceNice change.
Comment #16
xjmSupernitpick: I think this is missing a final period, since it's a sentence rather than a single phrase/label.
Also, saving issue credit.
Comment #17
shimpy#16 I have rebuild the phrase.
Comment #18
Wim Leers@shimpy Why did you change the wording much more significantly than @xjm asked for? Please just add the trailing period 🙂
Comment #19
shimpy@Wim Leers
I changed the phrase because as @xjm mentioned in#16 it is a sentence not a label or phrase so we require final period after that.
As per my understanding, if we will mention like below then no trailing period is required as itself completes the label and will maintain symmetry with other JSON API labels
+ 'value' => t('Allows all (create, read, update, delete)operations')
Please check. I might be wrong as well
Comment #20
shimpyReview
Comment #21
Wim LeersAFAICT this is what she meant :)
Comment #22
shimpySorry @Wim leers
I think I am misleading you. What I meant is if we put period in sentence then it will not act as label and will loose its symmetry with other labels. Attaching screenshot for reference. This was what I meant. May be I am not understanding the concern.
Comment #23
alexpott@shimpy is correct the value part of a requirement shouldn't have a full stop - see screenshot of existing sentence in a value...
Re-uploading #14 as that's the correct patch as far as I can see.
Comment #24
alexpottLol... context... so the Drupal core update status warning does not have a full stop but the experimental module warning does ... /shrug we are inconsistent. But the fullstop is much rarer. See screenshot:
I think there's a better way. One sec and I'll post a patch.
Comment #25
alexpottI think the attached patch is more inline with what value is expected to be. It also means that if you change to read-only the information is still there and hasn't suddenly gone missing.
I've updated the screenshots in the issue summary.
Comment #26
Wim LeersThis is why I was quietly complying without complaining 😇
This works for me too.
Comment #27
shimpy@alexpott and @wim leers #25 seems more consistent. Works for me as well.
Comment #29
webchickAwesomesauce!
Committed and pushed to 8.8.x. Thanks!
Wim and I debated backporting this to 8.7.x (it cherry-picks cleanly), since it's a security improvement, but also a string addition. Thoughts?
Comment #31
shimpy