yes this is really anoying!

If I remember the problem is that if we added a delete custom dimension button, the previously tracked data for that dimension would still exist in the so called "log" tables which stores the raw data. If you then create another dimension, that slot would be used again and your old data mixed with new data.

Deleting this old data is not "trivial" as it may take a long time to delete this data, and obviously cannot be undone. Accidental delete would not be possible to be restored. Maybe we could start adding a command that allows users to actually delete a custom dimension and also deletes the data from the log table. This way it should not happen "accidentally" and as the script would not time out on the command line (since it could run for a very long time).

I presume the workaround is to add more custom dimension slots if needed.

Maybe we could start adding a command that allows users to actually delete a custom dimension and also deletes the data from the log table. This way it should not happen "accidentally" and as the script would not time out on the command line (since it could run for a very long time).

This please. When playing around with new sites it is a hassle to have delete it, as that is the only way to get a "clean state" for a site.

I'm waiting for the day someone added a couple of dimensions to a production site, not knowing there isn't an easy way to remove the dimension.

We're doing this right now, trying to figure out which dimensions we need to use and how they work. We've had to create multiple sites just to test different ways. We still have an old dimension for the real site that we want to get rid of.

If people "accidentally" delete their custom dimensions, they either need to pay more attention or the UI needs to be improved. Removing the feature isn't a good solution.

Adding a CLI command to do it is nice, but unfortunately, not everyone that manages Matomo are too familiar with CLI though. Marketing people don't tend to be interested in learning how to ssh to a docker container running on kubernetes just to be able to remove a custom dimension. And it isn't something that they should need a developer to help them with.

If people "accidentally" delete their custom dimensions, they either need to pay more attention or the UI needs to be improved. Removing the feature isn't a good solution.

There could be a popup asking them to enter some text like the name of the custom dimension or type OK or something to confirm the deletion.

The problem be still generally that we would basically need to delete all the data from the log tables right away which can take quite anything from few seconds to few hours depending on the amount of data plus can cause down time. Not sure how this can be solved yet. It be probably more like a "delete from the UI" but keep it still in the DB meaning it wouldn't be possible to reuse the deleted slot.

If you created custom dimension for visit instead of action by accident just change matomo_custom_dimensions.scope column value from visit to action in the database.

Doesn't this do what you requested?
https://matomo.org/faq/reports/how-to-delete-a-dimension/

Doesn't this do what you requested?
https://matomo.org/faq/reports/how-to-delete-a-dimension/

If you have access to the command line, it could work, but in an organization where you care about security and follow the principle of least privilege, only a few should have that access, and that's rarely the same people that sets these things up through the UI. And they would probably rather work on more pressing things than this anyway.

"Accidental deletes" could always be prevented to a great extent with some UI tweaks, so I don't buy that as a reason not to have it. If you need to delete all the old data, inform the user (or even let them decide if they want to do that) and just let it take the time it takes, as long as there's an option to do it without needing to involve other departments.

Another alternative would be to somehow keep track on when a dimension was changed and handle it when fetching/presenting/aggregating the data (like removing/not fetching data for that column since before it was changed. It could even be a choice when deleting or changing a dimension). Then you would actually still be able to retrieve the old log data if you ever needed to.

Yet another option would be to rethink the database/system architecture to not having fixed columns for things like this, but rather having it dynamic, so you can add/remove dimensions as you please, without needing to alter any database tables (which is always scary to do on production databases).

Imho, it's completely fine to do some extra steps when you initially set things up if it means less maintenance down the road. Make the UX a part of the architectural design process. It's after all there most people spend most of the time once the application has been deployed.

I do appreciate that changing the underlying architecture would be a huge undertaking to say the least, and that it would take a lot of time, so I wouldn't expect most of it to be solved anytime soon, but if you have a vision where you want to go, you can start moving and preparing for it in iterations, making "patches" (like adding the possibility to delete dimensions from the UI, letting it take the time it takes) along the way.

Sorry for the lengthy rant, but it's just so common that companies are doing things backwards, like letting their tech/current architecture decide how a tool should be used (which I to some extent get the impression of here.) It's a bit like designing a house based on your toolbox, instead of buying the tools you need to build the house you want.