I am trying to work out what is the best way of setting up entities which represent the same thing (but with different types of detail). For example employees who are also Fibery users.
At the moment, I am working on setting up the various apps and testing them myself before rolling it out to other members of our team. As time goes on and more of my team work on the system, which means some (but not all) of the employees in the Employee Management app would also be users. I would like to ensure that this link is properly represented in the data model and that I can actually use it to drive some actions. For examples, during a bi-weekly one-on-one, some tasks may arise which I may want to assign to my colleague. It would be great if the task could be assigned to both the employee entity and the user entity.
While I was trying to figure this out, the only thing that came to my mind was the sameAs property.
I think there would be other situations where I think this would also arise (I can try and come up with some others if it is helpful).
@cannibalflea In fact we did have several discussions around the problem last year and came up to similar solution. In general, there are several cases where it can be useful. So far we want to solve this problem via Human extension that will link some entity to real User. Not sure when it will be done though, since this is not a very easy taskâŚ
@mdubakov As thee is huge potential , surely massive scal up can be made possible , it can be easy , but not impoosible , indeed the task app is vey elementary , as aldready inted out in the blog by @mdubakov , but tis is for people too , how get organis one make the team get help , as no code approach more validation than idea creationa , the problem wel solved.Recent very small grooup start up from brasil calle rocket chat , started from slack combined whats up , they usees comunication based problems , project , now able to go very big very short time thus people inclusion acess ,thus the idea @mdubakov is good teambuilding within fibery flatform , me too face this problems .This indeed the weak point , using slack type canal rocket chat any one make his group in mints put idea invite peiople get partner thus imposible , not easy , the comunity growth is plus points , so hat easilty all can use fibery platform to get things done many problemas based on projct and task, time well planned . trello for big teams , big projects .The fibery recent execution , is an app integrate may other well made study case. Such pratical better whit bar ,ux , stiry telling need more people some one give idea other make apo integration some validade , , finaly well test by many non coder can help fibery better interated app of fibery platforms ,wish prosprous 2020 for all the fbery team and all user comunity too
@mdubakov, wanted to chime in here too - this is a big pain point in a lot of other apps and it would be great if you guys could handle this more cleanly. What Iâve found is when you set up âusersâ in stuff like Jira, Zoho, etc. they do not have any properties of actual âstaffâ that you might want to track in your HR area. So you wind up with 2 instances of âEmployee xâ - the user account, and then the entity in your HR App, the latter you use say when you actually go through hiring this employee. I could definitely see leveraging the Fibery schema to have in fact two linked entity types, as it appears you are thinking along those lines. As long as the solution allows for the admin both to deal with the user account, and the actual âstaff memberâ in the HR app, and treat them as much as possible as the same actual person, youâd have a great solution.
I have not seen any app that actually properly considers that the users on your account are also your âstaff members,â and should be represented in the âTeamâ app, etc. I am glad to hear, if Iâve understood, that you guys are thinking this through and intend to try to solve this. I trust you will come up with a thorough solution, and I for one would gladly wait for this to be solved down the road, with the assumption that you will get it right!
I was thinking about this issue, and wondering if it canât be solved relatively easily by using the People App and using a tick box field for the people entity type to indicate that the person is an active user of fibery or not (as opposed to just being an employee).
[Any necessary extra entity types that are people-related can be created in an Employee Management app.]
It does mean that youâd be paying for People who arenât really fibery users but I notice that Fibery already has the option to deactivate users (and you donât get charged for them) so we just need to be able to link to âdeactivatedâ People as entities âŚpretty please!
[FYI, this feature would also help me immensely during initial app configuration, before users are allowed in for real]
Also, it would unfortunately mean that people who are just employees would be overloaded with fields that are relevant for employees who are fibery users, and vice versa.
But when the fibery team implements sophisticated field logic (allowing field visibility/options to be dependent on the value of other fields) - hint, hint! - the functionality can be different
i.e. the value of the âActive?â field enables (or disables) other fields.
Does that sound reasonable, or have I misunderstood the problem youâre having?
Another follow-on thought. The problem kind of relates to the issue that, sometimes Iâm using fibery in my capacity as Admin, and sometimes in my capacity as an employee/user. It would be nice if I could achieve this without having to pay for two licences or having to log out an in again.
Iâm pretty sure the team are working on an update to the access/permissions functionality, which is a bit underdeveloped at the moment, so I keep my fingers crossed that their great brains will be able to amaze me with a solution that solves both of these things.
but I notice that Fibery already has the option to deactivate users (and you donât get charged for them) so we just need to be able to link to âdeactivatedâ People as entities âŚpretty please!
or having to log out an in again.