snipe / snipe-it

A free open source IT asset/license management system
https://snipeitapp.com
GNU Affero General Public License v3.0
11.12k stars 3.19k forks source link

Request Add Department like Company field to Assets #8072

Open circuitswitch opened 4 years ago

circuitswitch commented 4 years ago

Hi,

Thank-you for the product. It is so much better than so many other things.

One little request. Assets have Company, but don't have Department fields. I would really like to add Department rather than Company (or in addition) so I can show a group of people within a Company own a particular asset.

I realize I could make Company work by adding multiple more granular entries in Company, but since we have Departments linked to Companies, it would be nice to leverage that field.

Thank-you!

circuitswitch commented 4 years ago

I forgot to mention, I see personnel have Department, but Assets do not. It would be nice to at least eyeball check that a person requesting an Asset actually belongs to the same Department as the Asset.

bra1ncramp commented 4 years ago

Currently Assets can be assigned to a company without being "Checked out". Unfortunately, there doesn't seem to be any hierarchy for Companies - which does not reflect the real world.

We need a way to account for assets that are designated for one department over another in a company.

Use case: We buy 100 laptops. We have three companies (A,B, and C)

30 laptops are for Company A's marketing department 10 are for Company A's accounting department 20 are for Company B's IT department 20 are for Company B's marketing department 10 are for Company C's sales department 10 are for Company C's accounting department

I need to be able to assign to Company AND department. I need to be able to search for all assets for Company A (checked out and ready to deploy), but I may also want to just search for the specific department. Currently, there is no way to do this.

twisted3motions commented 4 years ago

Agreed

sjackson0109 commented 4 years ago

I was discussing this very issue the other day.

stale[bot] commented 3 years ago

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

circuitswitch commented 3 years ago

Yes!!!!! Respectfully,

Brian Chesney

On Fri, Dec 25, 2020 at 3:23 PM stale[bot] notifications@github.com wrote:

Is this still relevant? We haven't heard from anyone in a bit. If so, please comment with any updates or additional detail. This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Don't take it personally, we just need to keep a handle on things. Thank you for your contributions!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/snipe/snipe-it/issues/8072#issuecomment-751287860, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIOHG5ZYSTMFJLSP3FR7X3SWTYDZANCNFSM4NHZH2TQ .

stale[bot] commented 3 years ago

Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

sjackson0109 commented 3 years ago

Just because the reported user hasn’t continually updated the ticket - it’s hardly fair to simply close their ticket, especially if it’s not been worked on, held stale by your side, due to your existing AD sync improvements all bundled into v5. Perhaps re-consider the auto-closure process - making it more fair all around?

This is a feature request - still highly relevant, even after your v5 improvements.

Please ensure these fields are sync’d and then automatically adjusted every time a user/person within AD moves department/company etc.

On 25 Dec 2020, at 22:06, stale[bot] notifications@github.com wrote:

 Okay, it looks like this issue or feature request might still be important. We'll re-open it for now. Thank you for letting us know!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

circuitswitch commented 3 years ago

Thank-you

eeintech commented 3 years ago

Still relevant even now, any plan to support both companies and department?

Thanks :+1:

LeeReitz commented 2 years ago

I would like to see this feature. I have noticed there are other feature request for department "checkout" which have been denied (understandably so). It would be appreciated if at first we can assign assets to a department and maybe later add some view filtering/permission to department. Similar to Company features.

baghirani commented 2 years ago

Very Important feature. And I have an addition to that: Not only that an asset and all the other stuff should belong to a department. The departments should have a hierarchy. And it should be possible to assign permissions based on the hierarchy. Because a manager of a small group should be able to view and even edit the items of his group, but he should not be able to do this for the rest of the company.

snipe commented 2 years ago

That's what Full Multiple Company Support is for. Just use Companies as Departments.

eeintech commented 2 years ago

That's what Full Multiple Company Support is for. Just use Companies as Departments.

Is the "Companies" model name modular and be renamed by admin? Mixin of words can be confusing so it could work if that was the case.

LeeReitz commented 2 years ago

According to the User Guides, Full Multiple Company Support is for multi-tenancy. Which won't satisfy all the cases we are discussing if data is properly segregated. The concepts of Company and Department are already exist in the application, we are asking for improvements on the department concept that imitates department structures in real life.

Several users have taken the time and asked several times for this feature. It appears Snipe being resistant to entertain the feature request, per responses to other requests. Is there system restraints that would cause this feature request to be unachievable or cause system issues? Is there other factors to consider? Would be considered if community developed?

baghirani commented 2 years ago

But you can't have a company hierarchy right? So it is not possible to set someone who can see the whole sub hierarchy. I have to create a big bunch of companies, that are not structured. Doesn't make it sense to just combine departments and companies, let the administration decide how to name each level and to make it configurable if there is a manager which can view all sub departments?

snipe commented 2 years ago

Is there system restraints that would cause this feature request to be unachievable or cause system issues? Is there other factors to consider? Would be considered if community developed?

System restraints, not exactly. It would require several database migrations to keep the functionality working as expected for most people.

I would likely not consider this if community developed. Building something is easy - maintaining it and securing it over time is a lot harder.

baghirani commented 2 years ago

Ok, I will try to put some stuff together, maybe there is a nice solution for some more issues, f.e. #(7359), #(8672), #(9621) and #(10347), I found, and I think there are some more.

For me this would definitely work, maybe for the others as well?

snipe commented 2 years ago

I would likely not consider this if community developed

You're welcome to go down this path, but I did already say I probably wouldn't consider merging it.

Hierarchy sounds easy, but then you will run into recursion issues for counting the numbers of people, assets, etc within a department. How many levels of hierarchy should be allowed? How do you make sure a child-department is not its own parent? Validation alone become a hellscape. Right now, dept names must be unique - we'll need to change that to be unique to company+dept combo. And then testing and maintaining it down the line is a whole other thing.

The way you use (or want to use) Snipe-IT isn't the way a lot of people do. Believe it or not, I'm not reticent for new things, but as the steward of this project for 9+ years, I'm the one who will be left holding the bag.