Custom DT tracking problems and possible solutions.
Last saved by Vladimir Opatski on January 13, 2015
As you know, our users can create custom DTs to work with their projects. So we need to handle this activities to let them access their DTs from every machine they have. For this there should be made some api and database adjustments.
But at first we should decide which way we want to track created DTs.
1. Create global DT list.
This is the easiest way to implement this feature and the least amount of collisions can cause.
Users can look through the whole list of custom DTs created by anyone and most likely won't create copies of existing custom DTs.
2. Connect custom DT to a project. User will have an access to all DTs of projects he has access to.
This is the best way to connect custom DT entries to something. But some problem persists:
Imagine if we have two guys working in one dt in different projects. So each of them created a custom dt and everything is fine. but if they want to work together in some 3rd project there will be shown 2 entries for the same dt. this behavior will be even worse when we have a lot of users collaborating together.
Pierre suggested to solve it this way:
But at first we should decide which way we want to track created DTs.
1. Create global DT list.
This is the easiest way to implement this feature and the least amount of collisions can cause.
Users can look through the whole list of custom DTs created by anyone and most likely won't create copies of existing custom DTs.
2. Connect custom DT to a project. User will have an access to all DTs of projects he has access to.
This is the best way to connect custom DT entries to something. But some problem persists:
Imagine if we have two guys working in one dt in different projects. So each of them created a custom dt and everything is fine. but if they want to work together in some 3rd project there will be shown 2 entries for the same dt. this behavior will be even worse when we have a lot of users collaborating together.
Pierre suggested to solve it this way:
[13.01.15, 15:08:07] p.seylan: we can do some sort of DT merging
[13.01.15, 15:08:10] p.seylan: imagine this
[13.01.15, 15:08:26] p.seylan: you and me work with the dt in different projects
[13.01.15, 15:08:32] p.seylan: then i invite you to my project
[13.01.15, 15:08:58] p.seylan: then in the client you are asked to confirm your dt setting
[13.01.15, 15:10:16] p.seylan: something like "it seems that you are working with the same custom software as other users in this project, to avoid problems we have changed the dt settings for this project, please review"
[13.01.15, 15:10:32] p.seylan: then you can review the dt settings
[13.01.15, 15:10:46] p.seylan: those will be the ones i used, because its my project
[13.01.15, 15:11:06] p.seylan: so you need to adjust in order to work with my project with the same custom dt as me
[13.01.15, 15:11:12] p.seylan: however there are 2 options
[13.01.15, 15:11:32] p.seylan: either we say that you need to adjust and will use the exact same dt settings as me
[13.01.15, 15:12:03] p.seylan: or your dt settings are set as the same as me, but you can edit them.
Also, there is a problem where users can create multiple entries for the same software with different custom DT name.
Also, there is a problem where users can create multiple entries for the same software with different custom DT name.
Comments
Pierre henri Seylan on January 27, 2015:
I took some time to think about this case and decided that we should implement the Global DT list for now, since it seems to be the safer variant.
However, we need a sort of validation mechanism to avoid that the list grows endlessly, for example if a user starts to add random DT's.
The problem here is the boundary between built-in and custom DT's, because if we start to integrate the custom DT into a global list that is validated by the admin, it ends up being built-in DT's as well.
Proposal:
A custom DT would have an attribute private/public, or user/global (to avoid confusion with projects)
This attribute would define if a custom DT is usable only by the user who has registered it (user), or if it is usable by all users (global)
All custom DT's would be first added as "user" type, and after some tests, we could decide to switch a custom DT from user to global, using the admin panel (where some of the DT datas will be managed)
let me know your feedback