I vote for global user preference only. It defaults to what we have now, but users can override this with a default action (global, not per collection/role). We could take that a step further and have a project default... but that's more of an add-on.

I vote for global user preference only. It defaults to what we have now, but users can override this with a default action (global, not per collection/role). We could take that a step further and have a project default... but that's more of an add-on.

Basically how I envisaged it. Though I did think it could be something people could toggle in their own profile, a global default would at a minimum be very helpful.

I vote for global user preference only. It defaults to what we have now, but users can override this with a default action (global, not per collection/role). We could take that a step further and have a project default... but that's more of an add-on.

This works!

Also would be nice if you could Hide these "Special Actions" , the ... button.
And fields "Clear Field" and "Raw Value" seems quiet odd feature to me as well. Users just don't interact with apps like this. If they want to clear the field, they will focus on input and backspace it or select txt -> delete. (Visibility options) for these would be nice.

Users just don't interact with apps like this.

Can you provide a but more insight regarding this? These features were added by request. Some interfaces are not as easy to clear (eg: a map, relational data, etc)... and with our support for custom interfaces, we need to have fallback in case developers forget to include these key features.

Also, any reason the "..." save menu should have an option to be hidden? Adding random settings like this can make the platform far more complex to configure, with little benefit.

No, extensions currently don't have the ability to override the save button behavior in-app 👍🏻

Another use case for refactoring Studio client/server logic into (scoped?) system-flows. Humongous refactoring project I know…but one can dream :)

I can also imagine the bug triaging nightmare 😂

Applying different functionalities to the same button doesn't feel like good UX.
So I tend to both button being visible - ideally on all pages for consistency.

I don't know if I agree there. There's 3 different save options + a discard changes option within that subnav; having all 4 as buttons side by side might be very confusing too

A part of the solution could be to make the different save buttons have different designs:
The default one could be red, as it is now, while the 'Save and stay' one could be white inside with a thick red border.

The default one could be red, as it is now

Do you have custom CSS configured? By default, it's purple (primary) 👀

Ooops haha, yes, the default primary color I mean. Not red

Due to the preview functionality personally it makes most sense for me to set the save option by collection. However by user is also good with me! Whatever makes it easiest to start with

One two more things:

• Per collection or global?
• Save it to the user to persist?
• Make it per session?
• Not make it persist at all?
  • By that I mean as soon as you navigate away from the item detail page it resets back to the default default
  • ^ that feels good

LOVE IT! How about a button similar to

?

My vote would be for per collection.
Per user persistence would be great.

Hmm wouldn't this make keyboard binding a bit confusing? I would expect CMD+S to be the default, and CMD+SHIFT+S to be the alternative.

It doesn't always trigger the page save, only when you have a textarea in focused. Clicking on the page outside any inputs or textarea and click Cmd+S works at least on my mac it does :)

I develop on Linux, Pop!_OS. It happens always. Anyway, your observation is beside the point: it is not a good user experience to have to use the mouse for a keyboard shortcut to work :)

Due to the way Directus is designed, as far as I know it is not possible to save the item content in a drawer (the right-side panel) independently of its parent item

This is on purpose 🙂 I wanna make sure you can cancel out of the changes you've made by leaving e parent item. Having all nested relational changes apply immediately without the parent being saved was a pretty rough UX.

Hi @jasonsuriano,

Thank you for the amazing work on your Directus plugin! The save-and-stay functionality solves a big pain point for me, and it has significantly improved my workflow. I really appreciate all the effort you've put into making it happen.

I did notice a couple of small issues happening on Directus 11.3.5, though:

1. Whenever there’s a validation error or an error thrown in a flow script, the button stays stuck in the progress state (spinning wheel) and doesn’t revert back to the check icon.
2. Occasionally, when I click the button, it enters the progress state (spinning wheel), but the save action doesn’t actually execute. I have to click the button again to trigger the save properly.

Would it be possible for you to look into these? I’d be more than happy to help test or provide additional details if needed.

Thanks again for your hard work—your plugin has truly made a difference for me!

Hi @BaelishCZ, thanks for letting me know. We haven't upgraded to the most recent version of Directus so this may be why we haven't seen this issue. We're planning on upgrading in the coming weeks, and I'll post once we've investigated, and have a solution.

Hi @jasonsuriano,

Thank you so much for your reply. I really appreciate you looking into this. No rush—take your time with the upgrade. I’d be more than happy to test anything or help troubleshoot if needed. Thanks again for all the great work you’re doing!

Hi @jasonsuriano,

I hope you’re doing well!

I just wanted to follow up and see if there’s been any progress. No rush at all — I know these things take time.

If there’s anything I can do to help test or troubleshoot, please let me know.

Thank you again for all your work on this plugin!

Same here @benhaynes

Directus is really amazing, but thing like this drastically diminish its user experience ☹️

Thanks for all the great work you’re doing anyway!

haha it’s an opinion thing more so than a technical limitation :) Despite what you see in this thread, when exploring this with our product team we found it’s very close to 50/50 on whether or not this should be the default so we haven’t rolled it out org-wide. That being said, we’re doing a bit editorial project at the moment that includes global draft states and other versioning improvements which comes with some changes to the save button behavior as well, so rest assured: this isn’t completely ignored 😉

I agree that neither approach should be forced on anyone. Just give us the choice to set our own default at the project level 🙏.

In our project, there is really no use-case for save-and-leave, so we have to train our users to use save and stay from the sub menu, or use the keyboard shortcut of cmd-s (which regularly stops working and triggers the browser's file-save instead which is super-frustrating).

haha it’s an opinion thing more so than a technical limitation :) Despite what you see in this thread, when exploring this with our product team we found it’s very close to 50/50 on whether or not this should be the default so we haven’t rolled it out org-wide. That being said, we’re doing a bit editorial project at the moment that includes global draft states and other versioning improvements which comes with some changes to the save button behavior as well, so rest assured: this isn’t completely ignored 😉

In this thread, there was a good explanation of why by Rolodato:
#4081 (comment)

It would be interesting to hear why someone might disagree. While the “save and close” option may be required for some specific use cases - there’s no doubt that someone will always need something special.