💡 Should we constrain applets so that, per database, names cannot be duplicated?

[shnizzedy]

Since we've made the design choice that anyone can create an applet from an existing activity set, it follows that multiple applets will exist for some activity sets (this is in fact already the case). This structure has caused persistent confusion, both with users and within the team. I wonder if constraining applet names would resolve this confusion.

[satra]

@shnizzedy - i thought activity-sets and applets were synonymous? but indeed one can create as many of them.

[shnizzedy]

@satra that's part of the confusion! Applets take an activity set (currently de facto constrained to one activity set per applet) and add things like users and schedules which are not part of the activity set.

[satra]

@shnizzedy - thanks for that clarification

[binarybottle]

I take it then that the decision is to constrain the naming of applets within a given database to be unique.

[shnizzedy]

I don't think we've made a decision unless by,

I take it then that the decision is to constrain the naming of applets within a given database to be unique,

you're saying that we are making that decision.

Since I'm getting questions like

Could you please invite [people] to install the HBN EMA applet?

I think the gap between the imagination and reality of how MindLogger works is still wide enough that it needs to be addressed, but I'm not confident this suggestion will sufficiently close that gap.

[shnizzedy]

Resolved

We shall constrain applets so that, per database, names cannot be duplicated.