Add workaround for quick button inconsistency #5422
Conversation
[ci skip] [skip ci]
pxpm
added
Minor Bug
| // this shouldn't happen, but in v6 we introduced the "quick" button with an inconsistency with other buttons. | ||
| // the quick button name is converted with `Str::studly()` to get the access string and that makes it impossible | ||
| // for this function to determine the proper access key. For example, a quick button with the name `comment` | ||
| // would have the access key `Comment`, while create, update, delete etc have the access keys `create`, `update`, `delete` without transformation. | ||
| // we should remove the transformation in vendor\backpack\crud\src\resources\views\crud\buttons\quick.blade.php and remove this line from here in v7. | ||
| $condition = $condition ?? $this->get(Str::camel($operation).'.access'); |
There was a problem hiding this comment.
Pedro, what do you think, instead of this long comment... that we keep this as a feature, and don't remove it in v7?
Why am I suggesting this?
- Because this is a DX problem that I've encountered too. It's easy to make typo with these, and it's a shitty thing to debug for 30 min. So streamlining the experience here could be a good DX win, as a result of fixing this bug.
- In my opinion, using
hasAccess('inline-edit')andhasAccess('InlineEdit')orhasAccess('inlineEdit')... should do the same thing.
Do you agree?
There was a problem hiding this comment.
I agree with the change. In fact, I'd make this the default going forward - that whatever gets passed to hasAccess() gets treated the same (InlineEdit, inline-edit, inlineEdit).
See my thoughts here #5422 (comment)
[ci skip] [skip ci]
|
After our talk we decided to do this change on the blade file itself so it only concerns the quick button. It's better to keep |
|
Also updated docs here: Laravel-Backpack/docs#541 |
WHY
BEFORE - What was wrong? What was happening before this PR?
Reported in #5421
Following a simple tutorial that should "just work", was not "just working" 🤷♂️
I've debugged the issue and the culprit is the fact that we
->studly($buttonName)to get the access string. So a button with the namecommentwould have the access stringComment.AFTER - What is happening after this PR?
It checks both operation name strings. First the regular one and as a fallback the
camelCasedversion of the operation.HOW
How did you achieve that, in technical terms?
I could have just changed the stub and define the operation button with
access => Str::studly($operationName)or just removed thestudly()in thequick.blade.phpfile, but that would be a BC at the moment in any of those cases. But it's what I've planned for v7.So I made it fallback to a camelCased version of the name as last resort to try to find access.
I don't think this would ever be a BC the way I implemented because it wouldn't be possible for you to have a
moderateand aModerateoperations, or aSuperModerateandsuperModerateoperations at the same time.Is it a breaking change?
I don't think so, no.
How can we test the before & after?
Follow the tutorial in Backpack website https://backpackforlaravel.com/docs/6.x/crud-operations#creating-a-new-operation-with-a-form-1 . It will fail previously, it will work after.