As a sanity check here before I actually build it, is anyone who is interested in configuring global default settings interested in configuring any settings other than mail-related settings? Or is this just T9161 in an alternate form, practically speaking?

Two aspects here, one or both of which may already be partially or fully implemented:

As requested by Chad, an attempt to describe our use-case:

All result pages have a "Hide Query" button now, I think since the last redesign.

The "role" stuff is mostly just practical/technical: we have to do about 95% of the same work whether we end up with multiple configurable sets of defaults or a single set of defaults.

This seems like it should be two separate tasks to me. Basically:

• Make Dashboards better
• Have user defaults admin settable (email, time, language, diff display)

It's been moving out of Config and into Applications gradually and I want to have ~all of it in Applications eventually, a lot of it just predates Applications.

It also seems strange to have some application config in Config and some in Applications

(The dialog might also be inaccurate if the link was actually on a dashboard panel.)

I could imagine this, purely motivated by flavor:

Yes, but it's real dumb:

Do you know why Applications application doesn't show in search?

mgroup

One other thing we might want to consider is making "Prototype" more prominent, just in the hope of reducing upstream support burden a little. We could link it to the "Prototype" docs too, perhaps.

I've been thinking about this for a while since the redesign, I'll toss a diff together today.

Would roles be able to have a list of default Projects (or Space?) which members of the role are added to? Or should we expect to migrate to role-based permissions?

I saw this note and got excited

...since we'll probably begrudgingly overload "roles" into permissions eventually (e.g., allow role-based policy rules).

Would roles be able to have a list of default Projects (or Space?) which members of the role are added to? Or should we expect to migrate to role-based permissions?

Just going to punt this into role profiles.

Let me try to rephrase: "I would argue that showing entire app components to users that cannot be used is a UX bug".

I would argue that showing stuff to users that cannot be used is a UX bug.

Case in point: as a non-admin, clicking on "Config" here:

I can only agree with your position WRT hypothetical requests, but this task is a UI bug in my mind, not a hypothetical request. There's no reason for a non-admin user to see admin apps at all, which they cannot do anything with anyway: it's just setting the user up for failure.

I haven't seen any reports of actual users experiencing real confusion. If and when we do, I'd prefer to tailor any solution here to their actual confusion (e.g., what were they expecting to see, what were they trying to do, why did they find this confusing), and imagine that hiding these applications is probably not the best solution (offhand, another solution might be marking these applications as admin-only instead). In legal jargon, this issue isn't "ripe".

In T8753#124642, @frankth wrote:

Can you help me ?

Can you help me ?

The biggest challenge for 3rd party apps, from my perspective, is the rapid rate of development in the upstream. Keeping up with the unstable api changes is definitely a challenge for anyone who isn't closely following Z1336: General Chat and watching the upstream commit log regularly.

Story is pretty much the same a year later, so I'm just going to update the "today" in the description. :3

We don't plan to pursue this in the upstream. Recommend subscribing to the Changelog to keep up with when things leave prototype.