Admin Permission Descriptions - Page 2 - D-Tools Forum

sburge · 01-19-2011, 10:03 PM

I would like the option of letting folks add new product to the database (via the project), but not allowed to edit existing product. I just thought it was odd that they could delete product, but not add product….unless I’ve misunderstood the permissions.

This would allow someone to “harmlessly” add product to the MMPD that I could later go back and edit.

**Ryan Brown** · 01-19-2011, 11:50 PM

There are 2 separate permissions in LanSync Admin -

1. Add/Edit Data - gives ability to both add and edit data in the database.
2. Delete data - gives ability to delete data

If you don't want them deleting remove that permission from their user group. If I understand your questions correctly, you won't be able to give Add permissions to your users without also giving them the editing ability.

tomsveraview · 02-05-2011, 11:51 AM

I think I have a scenario by which my organization can effectively maintain the database without tripping each other up. Before I implement this I'd like some input.

I am the database administrator, so I get the following permissions:

Add/Edit Data
Delete Data
LANSync Data Sync
Data Administration Page

My Sales Engineer adds new products to the database, and keeps pricing current. Their permissions are as such:

Add/Edit Data
LANSync Data Sync

My draftsman keeps all the inputs and outputs and product specifications in order. While he's creating drawings he can add or fix inputs, outputs, etc:

Add/Edit Data
LANSync Data Sync
Restrict Price
Restrict Cost

Our Salespeople aren't allowed to manipulate anything in the database. They may be working on a deal where they need to adjust pricing in a project, but they don't get to write that information to the master database. They get:

No permissions whatsoever.

Lastly, everyone in the organization will be set to LANSync when they log in every day, so if changes they made need to persist they will.

**Ryan Brown** · 02-07-2011, 11:20 PM

Make sure to give your salesman the ability to LanSync in permissions. since you've disabled their ability to update the database the syncing will essentially only be moving new data from the server down to them, not from them to the server.

Otherwise sounds like a great plan!

tomsveraview · 02-08-2011, 12:00 PM

Thanks! Didn't totally mean to screw the sales team not being able to LanSync - even the best laid plan has a hole or two in it

We want to divide and conquer the database maintenace, doing it this way is intended to build it into our daily workflow, just leaving bulk pricing updates as necessary.

**Ryan Brown** · 02-08-2011, 03:13 PM

I meant to say that your plan is an excellent way to move forward. It allows you to get started using the software immediately (more or less) which is always a good thing. The sooner you can get some ROI from D-Tools, the better!

Some have found it helpful when dividing data maintenance duties to use custom properties to keep track of things like 'last update date' or 'data verified (y/n)'

**Dave Kirn** · 02-09-2011, 12:15 AM

Looks like you have put alot of thought into how you want your process to work. Like Ryan said, you need to have some way to track what has been done with the data and what "state" the data is in since there are multiple people involved in creating/maintaining the database.

tomsveraview · 02-09-2011, 11:25 AM

Ooooh, that just turned into a feature request! Product last updated on (date) by user (toms), fields updated (cost,price,inputs). Maybe a "product history" tab!

fryeguy · 02-10-2011, 12:01 AM

Yes! A product history tab is an excellent idea. Especially if it gives you the opportunity to roll back a changes that you or someone else makes. I know that features like this require a more robust database. The good news is I know that the D-Tools developers are working on a more robust database...