Given that I have this kind of hierarchy in my Thingsboard:
-Root Customer
--Customer 1
---Child 1.1
--Customer 2
---Child 2.1
---Child 2.2
, where Customer 1 and Customer 2 have their own admin accounts I need to show all customers that a user has access to on a widget.
The problem is that I can not make a correct alias for a widget to get "all my customers" as a list.
Root Customer must see Customer 1 and Customer 2 and their children.
Customer 1 should see "Child 1.1" and "Child 1.2"
Customer 2 should see "Child 2.1" and "Child 2.2"
I have tried:
Entity list, but it there is no option to show all (or idk how to do it)
Entity name, but there is no wildcard of that I know, so I can only filter them, but not show all
Relation query, but it doesn't show Customers inside any chosen Customer
So question is: How do I make a proper alias to show "My Customers" in the widget
I found the answer myself.
Ownership in Thingsboard is not a Relation. So you have to manually create those relations inside the entity as they are not automatically created.
So even if Root Customer owns Customer 1, they are still not related unless you explicitly created that relation.
So Customer Hierarchy page shows you hierarchy based on ownership, but widgets only show it by Relation.
Related
I have a Rails 5 app with 2 models : User & Application
User can apply to another User through Application model
When an Application is created by User 1 to User 2, both users can see it inside their Application#index view.
Each User can delete an application, but that must not impact the visibility for the second user involved.
Example :
User 1 apply to User 2
User 1 and User 2 have the application inside Application#index view
User 1 soft delete application
User 1 do not see the application in Application#index
User 2 still see the application in Application#index
What is the most correct way to deal with this situation ?
Create 2 column sender_deleted & receiver_deleted and fill them accordinately with date + scope {sender_deleted: nil } for index
Create an entry for each user in Application then retrieve only the ones for each user ?
Other way ?
The second way seems proper, but the only info that differs in the table is the deletion date so it seems a little redundant.
Please note that I use the Paranoia gem for regular soft delete in my other models, not possible here with the 1 solution but possible with the second as only one column will be necessary to define the user as deleted.
I don't know what's the best way to solve this problem and I'll appreciate your help.
This is what I want to achieve:
There is an Act model. And it has many Organizations.
An Organization can have many Groups and also, a Group can have many Subgroups.
The Groups are loaded dynamically depending on the selected Organization, and the Subgroups are also loaded depending on the selected Group.
An Organization could have a Group or not, and also a Group could have a Subgroupor not
Here you are a mock-up of what I have explained above:
In the new Act form there is a section to add Organizations, something like this:
When you write an Organization it loads the options for the Group selector, and the same happens with a selected Group and the Subgroup selector:
When you click the add button, a new Organization section appears
A field can be empty. (This is a valid form)
Also, If you want to edit the Act, the form should show the Organizations added before:
I have this DB:
ActOrganizations is a polymorphic table, and also a join table
My main problems are about the form: how to build it to retrieve and persist the data easily and how to retrieve the stored Organizations to show them in the edit form. (I'm using simple-form)
I tried many approaches, but they were not very elegant. I'd like to know the closest way to the "rails-way" to do this.
Thank you very much for your time
Users have many tasks. (tasks.user_id = user_id)
tasks have many tags (implemented through Acts as taggable on
Users have many lists -> which have many tasks (A list is just a wrapper for multiple tags, for example {List id => 1, name => "shopping vacation summer"} will retrieve all tasks tagged with all of those tags)
If, for example, a user goes to the url tags/shopping%20vacation, my code would do a lookup for:
Task.all.tagged_with(["shopping", "vacation"])
There is no Lookup table or foreign key for task.list_id
I want users to be able to share tasks, lists, and tags with other users.
A user sharing a task shares just that task with another user.
A user sharing a list opens up all the tasks in that list to another user.
A user sharing a tag opens all of that users tasks tagged with that tag to another user.
To me, there are a few options, and I'd like some input on the pluses and minuses of each that I may not have thought about.
One is a distinct table for each shareable item:
shared_tasks: task_id, shared_to_id(or user_id)
shared_lists: list_id, shared_to_id
shared_tags: tag_id, shared_to_id
OR: a polymorphic association with
shareables: shared_id(item_to_share), shared_to_id, shared_type
What are the pluses and minuses of each?
Is there another solution that I haven't thought of?
Personally I would change the schema design. Taking Tasks as an example i would now treat it as a many-to-many relationship with User instead of many-to-1 as it is currently. So this would mean removing column tasks.UserId and adding a new table called UserTasks which links Tasks with Users defined as (UserId, TaskId, IsOwner). IsOwner is set to 1 for the user who the task belongs to and 0 if it is shared but belongs to someone else. This will make queries easier for example you could do do a single select to get both owned and shared tasks rather than 2 separate queries and also avoid union's.
I need to build one instance of django admin that can be used by multiple companies.
the schema is :
Company1
Branch 1
User 1
User 2
Branch 2
User 3
.......
Company 2
Branch 1
User 4
User 5
Branch 2
User 6
.......
The idea behind this is that user 1 and 2 is able to see (but cannot edit ) user's 3 stuff. Where as users 1 and 2 can see and edit each other's content. All this within the Company1 scope (only).
My question is are there any devs out there who's faced a similar problem and want to share their thoughts on how this can be achieved in dj admin? Any additional packages which can be utilized to extend dj admin functionality in right direction ?
Im aware that this challenges the idea of what was dj admin designed for (no need to caution about this ) ... but since there isn't enough hands to design and build something from a scratch for this project i need to tap into dj admin functionality as much as i can.
All thoughts will greatly be appreciated !
I was in a similar situation, with the added requirement that a user may be in multiple companies, and can "switch". For that purpose I put the "current company" into a session. If in your case you'd just be looking up in the user what they're allowed to see, it should be very easy, by overriding ModelAdmin.queryset, for example:
class CompanyGogglesAdmin(admin.ModelAdmin):
def queryset(self, request):
qs = super(CompanyGoggleAdmin, self).queryset(request)
user_company = request.user.company
return qs.filter(**{ 'company' : user_company })
You could use CompanyGogglesAdmin as a base class for all those models that can be filtered by "company" which gets looked up by the user's company. You could also make that company field configurable, or - like I did - look up the "current" company from a session rather than the user. See also How can I implement a global, implicit filter in Django admin?
I have a User model in my app, which I would like to store basic user information, such as email address, first and last name, phone number, etc.
I also have many different types of users in my system, including sales agents, clients, guests, etc.
I would like to be able to use the same User model as a base for all the others, so that I don't have to include all the fields for all the related roles in one model, and can delegate as necessary (cutting down on duplicate database fields as well as providing easy mobility from changing one user of one type to another).
So, what I'd like is this:
User
-- first name
-- last name
-- email
--> is a "client", so
---- client field 1
---- client field 2
---- client field 3
User
-- first name
-- last name
-- email
--> is a "sales agent", so
---- sales agent field 1
---- sales agent field 2
---- sales agent field 3
and so on...
In addition, when a new user signs up, I want that new user to automatically be assigned the role of "client" (I'm talking about database fields here, not authorization, though I hope to eventually include this logic in my user authorization as well). I have a multi-step signup wizard I'm trying to build with wizardly. The first step is easy, since I'm simply calling the fields included in the base User model (such as first_name and email), but the second step is trickier since it should be calling in fields from the associated model (like--per my example above--the model client with fields client_field_1 or client_field_2, as if those fields were part of User).
Does that make sense? Let me know if that wasn't clear at all, and I'll try to explain it in a different way.
Can anyone help me with this? How would I do this?
STI is probably a good fit for your requirements, as suggested by tadman, if you are using ActiveRecord (from Rails 3, it is easy to change ORM). The basic information is available on the AR documentation page, but here is some extra information w.r.t. your target:
Define one model per file. Otherwise there are some initialization troubles. Assuming Client inherits from User all in a single file, Client objects cannot be created as long as a User constructor has not been called once. One file per model circumvents the problem.
All attributes through the hierarchy are defined one-shot in the top class. This is for performance issues, but it seems disturbing many people in blog posts. In short, the Ruby code is object-oriented and encapsulates properly the attributes. The DB contains everything in a single table, with the extra "type" column to distinguish where they belong in the hierarchy. This is only a "trick" to represent inheritance trees in relational databases. We must be aware that the ORM mapping is not straightforward. The image on this site from Martin Fowler may help understand the situation.
In addition, you would like any new user to be a client, where Client inherits from User. To do so, you may simply instantiate any new user as a client. In your controller for creating users:
user = Client.new
# Do something to user
user.save
#=> <Client id: 1, name: "Michael Bolton", email: "mike#bolton.net", created_at: "2010-05-30 03:27:39", updated_at: "2010-05-30 03:27:39">
All the above is still valid with Rails 3 when using ActiveRecords.
It looks like you have two reasonable approaches here, but it will depend on the nuances of your requirements.
You can use Single Table Inheritance (STI) to do what you want, where User is only the base class for others named SalesAgent or Client and so forth. Each of these sub-classes may define their own validations. All you need for this to work is a string column called "type" and ActiveRecord will do the rest:
class User < ActiveRecord::Base
end
class Agent < User
end
The alternative is to have a number of free-form fields where you store various bits of related data and simply interpret them differently at run-time. You may structure it like this:
class User < ActiveRecord::Base
has_one :agent_role,
:dependent => :destroy
end
class AgentRole < ActiveRecord::Base
belongs_to :user
# Represents the agent-specific role fields
end
That would have the advantage of allowing for multiple roles, and if you use has_many, then multiple roles of the same type.