Fibery users should be entities just like any other

“Can login” should be a trait or behaviour that can be added to types in Fibery.
I elaborate more on how this could work at Convert entities of one Type to another Type.

E.g. I don’t want synced github members, and then have to manage sync between github issue assignments vs Fibery user assignments. Instead, I want to be able to select github members and allow them to log in.

It’s an interesting idea, and would certainly help me in some circumstances (I want to be able to record all employees but only some are Fibery users).
Are you suggesting a checkbox at the Type level or the Entity level?

Also, what happens if you set ‘Can login’ to true for a Project or a Task?! :-/

I’m intrigued to see how the Fibery team will handle more garanular permissions, since this is definitely something in the pipeline.

1 Like

Depending on what your total need is, I think this would rely much, much more on an entirely separate feature that hasn’t been talked about much, if at all: login (or “authentication”) integration with other services, e.g. Google, Github, etc. Which I think would be a nice thing to have.

That said, it sounds like a good part of what you want is just to be able to connect a Fibery user/entity to a Github user/entity. Is that right? If so, can you get specific about exactly what you want that connection to do for you, what it will allow you to do that you can’t now? Do you really need Github users logging in, or do you just need to know that “John” on Github is also “John” in Fibery?

1 Like

If you set login to true on Project or Task that probably means that you have ProjectManagers or TaskMasters logging in. What I mean is that if you’re doing it, it hopefully makes sense in your context (as with any field).
It’s more than a checkbox, it’s a whole set of properties and functionality.
It’s also an example of why I think that rigid types are wrong. The type name should be just a label. The type should be the composition of all its traits. I.e. you shouldn’t have to convert entities of type A to type B: you should just be able to add/remove the same traits to/from A until it has the desired behaviours and shows up in the desired places.

Partly why I’m arguing for this is because I’ve been using CMSs that implement this type of pattern for many years. E.g. adaptation in the Zope Component Architecture, or ContentParts in Orchard.

1 Like

Yes, I want to know that John in Fibery is gitjohn on GitHub, and belongs to the Support team, etc, without dealing with the same thing represented in different places. I want to be able to @-mention John without thinking about whether I’m referencing a Staff entity (in order to surface their office location, team memberships, roles), or a Fibery user (in order to send a notification) or a github user.

I’ve already gone through this misery with Notion where I have a Team table for all current and former staff and contractors, that can be referenced from docs and meetings to make those references meaningful to new joiners and far into the future, whereas username references would be opaque and transient as users come and go. The misery is that people naturally default to using the lossy noisy Notion user reference.

I think what you’re talking about would also start to address this issue: