Was asked to relay this feature request from team members.
They want ability to rename all fields, specifically so we can make them Norwegian and /or give them clearer meaning to anyone that uses the field.
One specific that comes to mind is the Workflow State extension. It allows renaming, but no other name seem to be valid.
I think this would be useful for “Assignments,” too. In the case where I have something that is more “owned,” like a Goal or Project, would like to be able to rename that field. We are both talking about Extensions including your case @Haslien.
Sorry to Segway, but I’d also like to be able to have the Assignments Extension repeatable. I have cases where I’d like entity “assignees” as well as “watchers,” or another type of “person” field like “supervisor.”
Thanks!
I think I mentioned elsewhere that it would be nice to be able to duplicate as well as rename Extensions (i.e. have multiple “instances” of an extension). That said would you want the Assignment extension to work exactly the same, just with a different name, for your described use case?
Hi!
Unfortunately renaming those extensions is a problem for our backend 
If this is crucial for you, then instead of a Workflows Extension you can just add a Single Select field 
The same for Assignment - that is just a relation between Type and User. The only thing is missed for this case - Notifications. But I suppose that Notification will be improved before we will allow extensions renaming 
Hmm, yes I suppose if you implement a more flexible/capable notifications system based on rules, then we could setup e.g. “notify user X on Entity Change when value of field Y = A” where “field Y” is a single select with the A being the user’s name, which we can map to an actual system user with this notification logic… Is that what you are basically saying may be possible?
Yes I’d like to add that I’m also curious about any information re: any progress on Notifications. I would particularly get good use out of date-based, as well as any way to have more control around user notifications - such as a pretty common concept of a “watcher” that gets notified when activity happens in an Entity. That is a fundamental of most other project management apps I’ve seen.
I think Polina is just pointing out that the assignment extension is basically no more than a standard relation (between an entity type and the user type) but with the specific functionality of notifications laid on top.
So when a more generic notification system is developed, similar functionality will be possible for any number of entity<->user relations.
So I imagine it could be set up so with auto-notification rules like: “Notify X when (boolean)” and here X can be hard-coded, or can be any expression that evaluates to a User.
e.g.
Notify Task.Watcher when (IsChanged(Task))
Notify Task.Owner when (Now = Task.DueDate)
Owner and Watcher are just normal entity<->user relationships
The nice thing about this is that standard entity<->user relationships can be defined as one-to-many, many-to-many or many-to-one.
Useful if, for example, I want to limit a task to having only one owner, or I want to limit a user to only be allocated to one department, or…
Ah yes, that makes perfect sense. Believe it or not I didn’t notice that User was a Fibery Type I could create Relations to!
Would very much like an update on that as soon as we can, with Automations showing in the latest WIP on Dec. 10 in twitter, improvements in Notifications are all the more relevant as that’s a key “second half” of Automations in all apps that have Automations in even a basic degree built out.