surrealdb / surrealist

Surrealist is the ultimate way to visually manage your SurrealDB database
https://surrealist.app/
MIT License
1.03k stars 73 forks source link

Modifying permissions in the designer fails #329

Closed caleblamro closed 4 weeks ago

caleblamro commented 4 weeks ago

Describe the bug Modifying permissions in the designer tab doesn't actually modify the permissions.

To Reproduce Steps to reproduce the behavior:

  1. Open the surrealist web version (I haven't tried the desktop version)
  2. Select any table and attempt to modify the permissions
  3. Click "save changes" to save your modifications
  4. Once the slideover closes, open it again and see that the permissions have not changed. You can also query 'INFO FOR DB' to verify the permissions have not changed

Expected behavior Permissions are properly modified

Environment:

Platform: Web
Navigator: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36
Version: 2.1.0
Flags: featureFlags: false, models_view: true, apidocs_view: true, themes: false, newsfeed: true
macjuul commented 4 weeks ago

I suspect there may have been an issue in the permission syntax, however the designer drawer would perviously not handle and display errors correctly. I've improved this where errors are now correctly displayed, allowing you to further debug potentially invalid values

caleblamro commented 4 weeks ago

Screenshot 2024-06-07 093357 image Thank you for doing that! Having error messages when the permissions are invalid will be awesome! I've attached some photos of the modifications I'm making to show you exactly what's going on. I don't believe the syntax is incorrect since when I make the modifications in the query tab, they work correctly. For this example I'm simply adding another scope to the select permissions on one of my tables. The first screenshot shows me adding OR $scope = 'user' to the select permissions, and the second screenshot shows the permissions after I've clicked 'Save changes'. I'd love to help with this issue, so please let me know if there's anything you'd like me to try!

macjuul commented 4 weeks ago

Interesting actually! You're supposed to prefix the condition with WHERE if not using FULL or NONE, however it appears the WHERE keyword is never restored back to the inputs.

I'll look into this further, however know that prefixing the conditions with WHERE should solve your issue for now. For the next release I'll attempt to make WHERE redundant to prevent further confusion

caleblamro commented 4 weeks ago

Ahh I see. I assumed since the WHERE clause wasn't in there to being with, I didn't need to add it. Once again, I really appreciate your help and the time you took to look into this for me.