mirror of
https://github.com/amidaware/tacticalrmm.git
synced 2026-04-26 06:55:52 +03:00
[GH-ISSUE #1254] Change devices Meshcentral Settings from within TRMM #2723
Labels
No labels
In Process
bug
bug
dev-triage
documentation
duplicate
enhancement
fixed
good first issue
help wanted
integration
invalid
pull-request
question
requires agent update
security
ui tweak
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tacticalrmm#2723
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fsteltenkamp on GitHub (Aug 23, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1254
Is your feature request related to a problem? Please describe.
I dont want to change to meshcentral to change settings of a device.
For example change if the user has to confirm the incoming connection
Describe the solution you'd like
Add the ability to change these settings from within TRMM, if possible also add permissions to do so.
Maybe have it as a policy so i can decide to require all workstations to confirm incoming connections, but not servers.
Describe alternatives you've considered
Currently i am changing these Permissions directly in Meshcentral. That works but is tedious because it is not really organized by customer or anything really and i have to search for a long time if the device is named something like pc001 which happens quite often...
Additional context
I am mostly thinking about the settings for user confirmation and notifications, but maybe more could be added.
@dinger1986 commented on GitHub (Aug 23, 2022):
You can set this for all the machines in a group, not the individual machine, or if there is an issue with servers or whatever you can move them to a different group.
I would suggest that as mesh is one of a number of remote access options for tactical that unless this can be achieved simply by the API it would be alot of work to implement this.
@fsteltenkamp commented on GitHub (Aug 23, 2022):
I Know i can set this for a group.
Can i separate devices into groups without tactical caring?
That would at least somewhat alleviate my problem.
But since i still think these settings should be configurable im going to look if it is possible to change them over api or cli.
If not, im going to open an issue on meshcentrals github, maybe they can implement these changes easily so tactical can interface with them.
@dinger1986 commented on GitHub (Aug 23, 2022):
Yes you can separate the groups, tactical doesn't care.
I'd imagine one of the devs should be about soon and can answer if it's a dev issue or whatever.
@silversword411 commented on GitHub (Aug 24, 2022):
Tactical only cares about the unique agent ID...and tracks that, nothing else.
I think the eventual plan is eliminating meshcentral in the future which would make this moot. Not sure if this should be kept around till that eventuality, or just close now.
@JSuenram commented on GitHub (Sep 8, 2022):
I am against eliminating mesh central for remote control... it is one of the finest remote-support and vpro/amt-solutions in the world and is really going forward with every release.....
It would in my opinion much better to far more integrate with MeshCentral and sync settings/groups/logon and much more between TRMM and MC. Especially when both run on dedicated instances....
@herzkerl commented on GitHub (Jan 29, 2023):
I’d prefer there were at least two groups created in MeshCentral—one for servers and one for workstations. I’d rather have the users accept incoming connections, but need unattended access to the servers.
I know, I could manually create another group and split servers and workstations (https://github.com/amidaware/tacticalrmm/issues/629 for reference), but since there’s also a discussion re: syncing MC and TRMM (https://github.com/amidaware/tacticalrmm/issues/182) I thought I might add that here.
@styx-tdo commented on GitHub (Feb 27, 2023):
I'd go further - one group per client, then split between server and wkst
Reason:
a) Permissions - should be granted per client in MeshCentral.
b) I am having no issues connecting to any server, but connecting to a client where someone is working may be a severe intrusion of privacy. Changing workstations to "ask" and servers to "connect" would fix this problem
@lambertpierre85 commented on GitHub (Feb 27, 2023):
I also need this solution but until the point where I can't specify which
clients are on free remote support and those not with a reportable log
sheet of hours spend on remote support to which machines from which support
agent I can't fully migrate from teamviewer over to TRMM (and pay support
subscription)
On Mon, 27 Feb 2023, 11:49 styx-tdo @.***> wrote:
@dinger1986 commented on GitHub (Feb 27, 2023):
You already can move machines. I don't fully understand though, do your techs not track their time?
@lambertpierre85 commented on GitHub (Feb 27, 2023):
we make use of remote support logs (currently teamviewer logs) to attach to
the invoices and also to track time of techs. Techs do support, admin
person invoices from comments attached to remote session and per logs time.
here is a sample of a teamviewer report attached. you can see the support
agents, session start date and time and end date end time, clients are
linked to a per hour billing rate and time spend is then calculating a fee.
makes invoicing easy for the staff
On Mon, Feb 27, 2023 at 1:34 PM dinger1986 @.***> wrote:
--
Regards,
Pierre Lambert
Cell: +264811409076
Fax2Mail: 0886510412
@fsteltenkamp commented on GitHub (Feb 27, 2023):
@lambertpierre85 i think you should open a separate issue for your problem.
it sounds like you want to implement time tracking into Meshcentral/Trmm which has nothing to do with the original issue i posted.
Yes, absolutely would be the preferred setup.
What i hoped this issue would result in, is a deeper integration of MC into Trmm, so i don't have to set up these permissions myself, and Trmm just sets them based on some rules defined in Trmm.
b) would have to be implemented by Meshcentral, since the "connect" button is just displayed as is by Trmm but generated by MC.
@NetBLOKS commented on GitHub (Aug 1, 2023):
Same issue here.
We need user right separation for Meshcentral, because not everyone is allowed access to every customer/ machine.
The No Autologin is a bad workaround, as we need the MC Login and all machines are in one group to be managed by TRMM. It would be much easier, if a user would be created on TRMM and MC simultaneously and synchronized.
This would also implement, that MC uses multiple groups, not just the "TacticalRMM" one for right-separation.
@silversword411 commented on GitHub (Aug 1, 2023):
We know what needs to be done. It's on the TODO list...it's just a matter of when dev resources can get to it.
@NetBLOKS commented on GitHub (Aug 1, 2023):
Good to hear, thanks for the feedback.