# Fibery users should be entities just like any other

**URL:** <https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518>\
**Category:** Ideas & Features\
**Created:** [April 3, 2021, 11:27am UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518 "2021-04-03T11:27:53Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jean1](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jean1/32/1669_2.png) [@jean1](https://community.fibery.io/u/jean1)\
**Post date:** [April 3, 2021, 11:27am UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/1 "2021-04-03T11:27:53Z")

</div>

“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](https://community.fibery.io/t/convert-entities-of-one-type-to-another-type/428/5).

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.

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [April 3, 2021, 11:56am UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/2 "2021-04-03T11:56:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\
**Post date:** [April 3, 2021, 4:52pm UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/3 "2021-04-03T16:52:01Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jean1](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jean1/32/1669_2.png) [@jean1](https://community.fibery.io/u/jean1)\
**Post date:** [May 7, 2021, 6:42pm UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/4 "2021-05-07T18:42:42Z")

</div>

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](http://grok.zope.org/documentation/tutorial/a-grok-centric-explanation-of-adaptation/tutorial-all-pages) in the Zope Component Architecture, or [ContentParts](https://docs.orchardproject.net/en/latest/Documentation/Basic-Orchard-Concepts/) in Orchard.

---

<div class="post-metadata">

**Author:** ![jean1](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/jean1/32/1669_2.png) [@jean1](https://community.fibery.io/u/jean1)\
**Post date:** [May 7, 2021, 7:02pm UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/5 "2021-05-07T19:02:23Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\
**Post date:** [May 8, 2021, 4:06am UTC](https://community.fibery.io/t/fibery-users-should-be-entities-just-like-any-other/1518/6 "2021-05-08T04:06:43Z")

</div>

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

> [@For HR Management, convert Candidate to User](https://community.fibery.io/t/for-hr-management-convert-candidate-to-user/1236/4):
>
> You’ll probably hate me for saying this, but have you thought about just using an Action Button? You could have a button for Candidates (called “Hired!”) which when pressed, will create a User and transfers the necessary info from the Candidate (name, email address, phone # etc.). The button could also trigger other things (like assigning the person to training, or arranging that they get sent a welcome bunch of flowers, or whatever slight_smile) You can also use the button to add the relat…

Cheers!
