I’m wondering if there is a way to do something like this:
Create a type, such as “task”, then create a child type of task, say “task for project2” that has all the properties of its parent type, plus any additional fields that I might want to use in that particular instance of the task type.
A related question: Is there a way to create field templates that capture your chosen edits to a field’s properties?
Hi, can you try to describe problems/use cases that you want to address? Maybe some solution is possible, but so far it is hard to grasp.
Might not be the best use case there, but I often end up wishing there was something like this. I feel like there has to be an existing request for this somewhere. The core problem is that you often have a Type that you want to customize for a particular use case, but you don’t want to mess up the core type that everyone is using. So, you either have to duplicate the type you want to extend, or you end up with domain-specific stuff making the core type messy. So, there is no way to share an encapsulated set of functionality across Types, which could be looked at as a similar concept to Mixins as well.
So, you could have Task, with name, description, assignee, state. Then, you could have a Campaign Task that marketing leverages, which adds a relationship to Campaign. You currently could create the Campaign Task today, but then you need to duplicate each field, action buttons, and rules. By having them completely separate, it takes more work to make sure the core functionality is in sync.
I think the Mixin concept could also be interesting because you could encapsulate a set of fields, rules, etc and apply them to an existing Type. Right now the only way to share functionality like this is via an entire App, which is harder to leverage if you already have something you are using.
Yes, I would also find this kind of approach handy. There has been various discussion of things like “global fields” and hiding of fields and whatnot which might also address these needs in various ways. But ideally some kind of “sub-type” or other more flexible “inheritance” would IMO be interesting and useful. I recognize some potentially significant UI/UX challenges though…