Skip to content
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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

albertsun
Copy link
Contributor

Part of #1593

Still WIP, probably to be merged after #1659 and along with #1660 after writing some tests.

This adds

  • A database migration that adds a shared boolean field to Agent
  • Updates to the agent form to allow shared agents as sources
  • A /agents/shared route to show the publicly shared agents

@cantino
Copy link
Member

cantino commented Aug 31, 2016

@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?

@albertsun
Copy link
Contributor Author

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?

@TildeWill
Copy link
Contributor

@albertsun I was wondering if there's a fairly "cheap" way of doing this. By representing organizations as a subclass of the User class. User already have all the right relationships to events and agents, the Organization < User would then hold the relationship to all the users that are members of that organization.

You could then reuse your 'becomes' feature to impersonate the organization.

UI changes would then be fairly limited to

  • asking the user if they want to act as their self or as one of the organizations they're a member of
  • allowing for organization membership admin

I'm sure it's not really that straightforward when you actually get in there, but maybe it's a path you could explore.

@cantino
Copy link
Member

cantino commented Sep 2, 2016

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.

@@ -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? } %>
Copy link
Member

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?

Copy link
Contributor Author

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
@albertsun
Copy link
Contributor Author

@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?

@TildeWill
Copy link
Contributor

@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(self.user == null) return self.organization all over the place.

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.

@albertsun
Copy link
Contributor Author

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?

@TildeWill
Copy link
Contributor

it's been a while, can we close this PR?

@albertsun
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants