New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Receive events from "shared" agents created by other users #1661
base: master
Are you sure you want to change the base?
Conversation
@TildeWill mentioned that it might be better as a concept of an Organization that a user is a member of. Would that work for the underlying case you're trying to handle? |
Hmm yes, in very large installs with lots of users I could see the list of shared agents and events starting to get very unwieldy. Organizations would definitely work too, but would be more complicated to implement I think. How would you think about implementing that @TildeWill - as a many-to-many of a new Organizations model with Users? |
@albertsun I was wondering if there's a fairly "cheap" way of doing this. By representing organizations as a subclass of the You could then reuse your 'becomes' feature to impersonate the organization. UI changes would then be fairly limited to
I'm sure it's not really that straightforward when you actually get in there, but maybe it's a path you could explore. |
I'd be worried that subclassing User to be Organization would ultimately add complexity, although I'm having trouble articulating why. I was thinking Users would be members of Organizations through an OrganizationMembership class. |
app/views/agents/_form.html.erb
Outdated
@@ -85,9 +85,9 @@ | |||
<%= f.label :sources %> | |||
<span class="glyphicon glyphicon-question-sign hover-help" data-content="This Agent will receive events from the selected Agents."></span> | |||
<div class="link-region" data-can-receive-events="<%= @agent.can_receive_events? %>"> | |||
<% eventSources = (current_user.agents - [@agent]).find_all { |a| a.can_create_events? } %> | |||
<% eventSources = (current_user.agents + Agent.shared - [@agent]).find_all { |a| a.can_create_events? } %> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about introducing Agent.available_to_user(user) as in Service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, adding that
… users Conflicts: app/views/agents/_form.html.erb
Conflicts: app/controllers/agents_controller.rb app/views/agents/_table.html.erb app/views/agents/all.html.erb
5b157cf
to
b00db24
Compare
@TildeWill are you thinking a single table inheritance thing with a "type" field in the database - the same way that Agents have subclasses? I'm more concerned about database complexity over time than about UI complexity. That seems potentially more vexing for future development. For the issue of large numbers of shared agents becoming noise - do you think of that as a problem in the UI being too hard to use? Or is the concern about permissions and privacy where people will want their shared events to be seen by some people but not all? |
@albersun, yes I was thinking of single table inheritance. It isn't my first choice usually, but I think it could make sense here. I'm picturing that the organization owns a set of agents, separate from the agents that the members of that organization own. As a member of the org, you can create/edit/delete agents in that org. If that's what you're going for then you still need some sort of common owner class, otherwise you end up checking If however you're envisioning that there are no agents directly owned by the organization, and instead members of an organization can all share, for some definition of share, their agents and events, then I agree with what @cantino describes. |
Ah got it, ok I hadn't realized that you were suggesting agents be directly owned by organizations. That makes sense to me as a possible way of doing it. I guess a broader question that should shape how we do this is - how are most people using Huginn? How many users does the typical install have? And looking forward how many users do we envision a typical install having? I'd guess right now there are a bunch of single user installs, one or a small number with lots (~how many @TildeWill?) of public users, and a handful of organizational installs with a moderate number of users. That sound roughly accurate? |
it's been a while, can we close this PR? |
I think the actual code of this PR is probably not relevant any more, but I would still like to see the underlying idea of agents that can be used at an organizational level or somehow shared between users move forward, if it still seems useful to others. |
Part of #1593
Still WIP, probably to be merged after #1659 and along with #1660 after writing some tests.
This adds
shared
boolean field to Agent/agents/shared
route to show the publicly shared agents