Hello, I would like to inquire about security settings in our system. We are using MP2 (SQL-Server 6 with patch 050319) that was recently migrated by a colleague from an older version. Unfortunately, this migration led to issues with incorrect indexes in some tables. Additionally, security settings were not properly configured, resulting in almost everyone having sysadmin rights. I attempted to create new roles but encountered a major issue - non-sysadmins are unable to create purchase requests, even when the new role has no limitations. How should I address this security concern and resolve the issue?
Assign the responsibility for creating purchase requests to each designated role.
Hey Josh, it seems like a good idea. However, from what I gather about MP2's security settings, creating a new role gives them almost all the same privileges as a sysadmin. My understanding is that I can restrict certain features in the security settings to limit their permissions. Am I mistaken in this assumption? How can I enhance the security of a role?
If you have recently updated to the latest version, you may have noticed changes in the security model tables and internal references. This may result in issues with the MP2 GUI. If you require assistance with the updated security tables, feel free to reach out to me at stuart.kiddle@gmail.com. The 6.0 update introduced significant changes to security, particularly with the introduction of multi-site functionality. If you are facing challenges with this, I am located in the UK and willing to assist. Feel free to send me a sanitized database for a review. Formerly worked with ex Datastream MP2 technical issues.
Hello Maintiger! If you need further assistance with setting up security, feel free to reach out. I can provide documentation and walk you through the process via phone call. Don't hesitate to contact me at jennifer.ohl@midwestsoft.com for help.
This indeed sounds like a tricky situation. When migrating, often there can be a flurry of issues that follow. Dealing with the mix-up in administrative rights sounds like the immediate priority. For a start, I'd recommend auditing who really needs sysadmin rights and make necessary reversions. Configuring SQL Server roles can be a bit complicated. Regarding creating purchase requests, it could be due to an improper mapping of the role to stored procedure or specific permissions might be missing. Carefully cross-checking the permissions associated with the new role and examining the database-level permissions needed for purchase order actions could be key. Also, any customization in your MP2 may need separate handling. Try to consult the MP2 vendor or refer to their documentation for more in-depth insights. This way you could eliminate security risks and retain necessary functionalities.
Hello! It sounds like you're dealing with a couple different issues here. First, regarding the incorrect indexes, it could be possible that some of the indexes weren't properly migrated or were overlooked during the migration process itself. So, reevaluating and potentially re-indexing those tables might be a way to address that problem. As for the security issue, it's alarming that everyone has sysadmin rights - that certainly exposes your system to potential risks. The problem with non-sysadmins being unable to create purchase requests even with max permissions sounds like a permissions issue within SQL itself. Specifically, it may be tied to the SQL Server role and permission levels set in the server, rather than within your software. It may be worth revisiting SQL Server's documentation or reaching out to their support for clarification on how permissions are structured. Also, you might consider consulting with a database security expert to ensure that the revised role configuration doesn't inadvertently compromise your system's security.
It sounds like you're dealing with quite a complex situation there. First things first, I'd recommend auditing your existing permissions to understand who has what access and rectify any inappropriate access rights - in principle, the idea of "least privilege" should be adhered to mitigate risks. For the issue of non-sysadmins being unable to create purchase requests, are there any specific errors popping up? It's possible that certain database permissions or stored procedures might be misconfigured. Secondly, you should also look into fixing the indexes discrepancies, as they could potentially slow down your queries, or worse, return incorrect results. It might be a bit time-consuming but taking these steps should help solidify your system's security and performance.
It sounds like you're dealing with quite a complex situation after the migration! First, it's crucial to ensure that your security settings are aligned with the principle of least privilege—only give users the access they truly need. As for the role creation issue, double-check the permissions associated with your new roles, particularly around the ability to create purchase requests. It might also help to review the existing user permissions and group memberships to identify any potential conflicts. You could also consider reaching out to your database administrator for their insights, as they might have encountered similar issues in the past or can assist with the indexing problem while you work on the security configurations. Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: Answer: Common security concerns during a system migration include incorrect indexes in tables, misconfigured security settings, and granting excessive permissions to users.
Answer: Answer: To resolve issues with incorrect indexes in tables after a migration, it is recommended to conduct a thorough review of the database structure and update indexes as needed to ensure optimal performance and data integrity.
Answer: Answer: To address the issue of non-sysadmins being unable to create purchase requests, you may need to review the specific permissions and access controls assigned to the new role, ensuring that the necessary privileges are granted to perform the required tasks. It could also involve revisiting the role configuration and possibly adjusting permissions accordingly.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.