Import assets from CSV file and local avatar

[votsdb]

I guess we should have the option that we can import our assets from excel file and also we can use our local avatar file instead of use gavatar.com

[votsdb]

and if possibility that we can attach the asset picture, that would be nice!

[snipe]

CSV import is on the roadmap, however local avatars and images of the assets are not currently planned.

[votsdb]

local avatar and images of the assets would be nice.

[snipe]

As I said, it's not currently planned, as there are much higher priority improvements to make. If you'd like to tackle it, by all means, we accept pull requests on good features, even if they're not necessarily ones on the roadmap.

[votsdb]

cool, yes please, thank you very much Snipe.

[snipe]

I don't understand what you're thanking me for. I'm saying we are not going to be working on local avatars or asset images, but if you would like to write the code that does it and submit it to the project, we would welcome it.

[votsdb]

ah, ok, I will do so, thanks again Snipe.

[Jengah]

Any predictions for a milestone on the CSV asset import? We love this tool and this would make the love even stronger :)

[technogenus]

We are currently working on our Beta3 version which includes CSV import of assets, licenses and service agreements and basic users. We expect Beta3 to be ready for testing before end of October 2014. http://cordeos.com/snipeit

[madd15]

Local avatars and images for models provided in pr #304, I think image on assets might be a bit much

[rp-tech]

If aphiniti devs have already got this feature working, why not add it to the main branch? This seems like a very useful feature. Problem is I would rather stick to the 'well-known' product aka the one that is being actively developed. I am sure Snipe-IT has no plans to end support soon vs a 3rd party who I am not sure about.

[snipe]

@rp-tech It is a long, annoying and dramatic story, but the short version is that their pull request had literally over 280 changed files. I asked them to break them down into smaller feature pull requests since their big one blew everything up when I tried to test it locally, and they took their toys and went home. The repo they were develping on has been deleted, and they are currently using my software under the guise of a complete rewrite (which it very clearly is not), in order to get around my Affero license (which they should not be doing, since the license still very much applies to them.)

[rp-tech]

Yup I definitely saw that when I took one single look @ their online demo, the first thing that came to mind was a bit of shadiness going on. I mean, FOSS in itself is great and we have seen plenty of nice clones of well-known open-source software and distros (look @ Ubuntu one of the most copied linux OS ever, which in itself started as a debian fork) but when you start stealing other people's ideas and claiming them as your own it's not cool.

Which is why I'd rather go with the original product!

[jotterbot]

+1 for asset import (any way possible).

I've just started moving our old Google Spreadsheet asset database to this app and am loving it (Currently having to "double handle" all new purchases though until asset import is resolved). The features of this blow me away - especially assignable assets - and is clearly the best way of running things.

I just have some 2000+ assets that need a way to get in to this app before I can swap over that doesn't involve me and a whole bunch of data entry. If this is marked with a "ready" label, can you clarify what remains to be done to see this feature in a release? Or at least in the develop branch. This is the only hurdle that stops me from being able to use this as our primary asset software, and I'm sure a lot of other people need a way to import assets.

Please don't mistake me though, I appreciate all the work you are doing!

PS. the behaviour of the other developer is appalling and I'm hoping you can take some recourse to a blatant violation of your license.

[rp-tech]

Another vote for asset import. CSV user import is working great for me btw - just had to make sure i used the exact format of firstName, lastName, email address otherwise it would not import! (for users without email I just specified a dead-end email e.g. noreply@mydomain.com)

[DanielNemanic]

I have created a workaround for local Avatars.

Our Company collects the pictures with the email adress in one folder under "public". This pictures are .jpg. I added the following to the app/config/production/app.php: 'avatarRoot' => 'Local Path like C:\snipe-it\public\Avatars\', 'avatarURL' => '/public/Avatars/', 'avatarFileEnd' => '.jpg',

Add the following lines to app/models/User.php on line 37 ( public function gravatar() ): if( file_exists( Config::get('app.avatarRoot') . $this->email . Config::get('app.avatarFileEnd') ) ){ return Config::get('app.url') . Config::get('app.avatarURL'). $this->email .Config::get('app.avatarFileEnd'); }

This checkes the "avatarRoot" folder with the E-Mail Adress and FileEnd .jpg.

[snipe]

@DanielNemanic I'm not clear what problem your solution is meant to solve?

[snipe]

Also, please do not suggest that users edit the core files. The next time we push out updates, those changes will be blown out.

[DanielNemanic]

I mean the local Avatar for a Person as a workaround. Maybe its a solution to everyone in the next release?

[snipe]

@DanielNemanic Local avatars will likely not be in the next release. It's not a very high priority feature for us, since so few people need it. Few people want to take the time to upload photos of their staff.

There should be no need to add anything to the app.php anyway though, as there is a {{ path('public') }} built into Laravel, and a {{ Config::('app.url') }} built in as well.

Overall, I don't think this is a good solution, and again, having people change the core is asking for trouble. Not to mention that if/when we do implement this, everyone who will have used this workaround is now going to have to re-upload those files, depending on how we solve the problem.

[Jengah]

Will this be making either the v1.3 or v2.0 milestones? I am in the same situation as @jotterbot and have assets in the 1000s that I would love to import into this awesome tool.

[jotterbot]

Surely the feature - getting data in to the app - would be ranking waaaay up higher in priorities then some other features? Obviously it's not if you have been using the app since the start, but this is a critical requirement for people to switch over from whatever they were using, and without it it's stopping more uptake.

If the "ready" label is accurate, what is actually stopping this from being implemented/merged? Even in the develop branch at least?

@snipe I'm hoping you can comment on the timeline - and I'm only asking as I am super keen to be rid of my spreadsheets and take full advantage of the features being implemented (as I'm sure everyone else is), but can't until I can work with my full dataset.

[snipe]

@jotterbot it is certainly high priority, but it is also non-trivial, as any decent import will have at least a basic respect of the relationships that come with it. Who an asset is assigned to, what kind of asset model it is, etc. Checking for all of those required dependencies, handling exceptions and validation, and implementing it in such a way that a larger CSV won't blow up the PHP memory - all of those things take time.

If we create an asset upload that just lets you upload the asset name and serial, every single one of your asset records will be missing critical information that makes the rest of the system work.

It all just takes time. It's not rocket surgery, but it takes time. The ready tag means that it's accepted as a roadmap item and is ready to be worked on. All it needs is someone to actually work on it.

[jotterbot]

I see! Apologies, I misunderstood the ready label - thinking that it denoted the actual code was ready and was being withheld from the repo for some reason (ie the fallout from that technogenus guy)...

Fully appreciate it is non trvial, and whilst I would like a base "asset tag, name, price,serial,date purchased" minimum form of import ASAP, I can understand how that wouldn't then utilise the full features of the app (ie what is assigned/not assigned to user, model types and so on).

At any rate, glad to have it confirmed that it is on your radar. I wish I had some skill with PHP so I could muster a worthy PR!

[Jengah]

That makes sense now that the ready tag has been explained. I too was under the impression that the "ready" tag meant the code was ready. On May 14, 2015 8:55 PM, "James Otter" notifications@github.com wrote:

I see! Apologies, I misunderstood the ready label - thinking that it denoted the actual code was ready and was being withheld from the repo for some reason (ie the fallout from that technogenus guy)...

Fully appreciate it is non trvial, and whilst I would like a base "asset tag, name, price,serial,date purchased" minimum form of import ASAP, I can understand how that wouldn't then utilise the full features of the app (ie what is assigned/not assigned to user, model types and so on).

At any rate, glad to have it confirmed that it is on your radar. I wish I had some skill with PHP so I could muster a worthy PR!

— Reply to this email directly or view it on GitHub https://github.com/snipe/snipe-it/issues/152#issuecomment-102219321.

[snipe]

@Jengah yeah, I try to explain what the tags mean in the Contributing.md: https://github.com/snipe/snipe-it/blob/develop/CONTRIBUTING.md

[Jengah]

Good to know! I am by no means a developer and hadn't thought to check the contubuting page [as i would probably be sub-n00b by common standards ;)]

Thanks for the direction!

[snipe]

No worries. :) I promise, it really is a priority for us. It's just a massive pain in the ass to get it working correctly. The relationships between these things are exactly why you'd want to use a system like Snipe-IT, so they're pretty key. I also run a start-up of my own, so while I spend a lot of time working on Snipe-IT, it's not limitless. Gotta pay bills, right? :)

I've added it to the v1.3.0 milestone, and will try to get at least a basic version up soon.

[Jengah]

Completely understand. I agree. The relationships are key and a breath of fresh air when compared to other solutions I have ever used or looked into.

You rock!! On May 14, 2015 10:15 PM, "snipe" notifications@github.com wrote:

No worries. :) I promise, it really is a priority for us. It's just a massive pain in the ass to get it working correctly. The relationships between these things are exactly why you'd want to use a system like Snipe-IT, so they're pretty key. I also run a start-up of my own, so while I spend a lot of time working on Snipe-IT, it's not limitless. Gotta pay bills, right? :)

I've added it to the v1.3.0 milestone, and will try to get at least a basic version up soon.

— Reply to this email directly or view it on GitHub https://github.com/snipe/snipe-it/issues/152#issuecomment-102241444.

[snipe]

[rp-tech]

jotterbot, also want to add you can always post a bounty on the issue if you want it resolved faster!

[mtucker6784]

Hi all, @snipe , thanks for all your work into your asset tracker. I work for a school district and it's hard to afford software on such a strict budget. Your tool fits in fantastically!

I have a question, and I don't want to start messing around in the database if I don't have to (although it's just the stock database right now with some assets of mine thrown in):

Would I be able to modify tables inside the database itself, in an effort to bulk import data from my existing inventory sheet, or does it become a bit more complicated than I'm thinking it would? For instance, how hard would it be to mass add categories for the "asset categories" section?

I apologize in advance if this is an odd question. I don't know the ins-and-outs and I'm not a heavy programmer, just enough to chop-shop stuff when I need to.

Edit:

I decided to give this a shot on my own---

1. I mysqldump'd the original database as a "just-in-case" scenario
2. Exported a csv from my current inventory
3. Created the information I needed (categories/models), grabbed the IDs created for each entity
4. Manipulated the exported sheet so it fit the columns under .assets and used the "Load Data Infile" command... Bam. All my stuff came over.

Probably not a very professional way to do it, but it worked, haven't come across any flaws yet.

Very exciting!

[nadroj08]

Hi Snipe,

I want to import assets with csv format I just want to ask where do I need to put this command "php artisan asset-import:csv path/to/your/file.csv --domain=yourdomain.com --email_format=firstname.lastname"

This command is came from your document http://docs.snipeitapp.com/manual/importing-assets.html

Sorry for noob question, I'm not a developer

[snipe]

@nadroj08 you run that via a command line terminal prompt, same as the php composer install and php artisan app:install

[nadroj08]

Thank you Snipe really appreciate your reply.

[djamelk]

Hi,

FIrst of all congratulations for your IT Management software we are starting to use it and it's very cool.

One problem i have though, is for the user importation, i import the csv file with the right columns, it says successful but doesn't import anything.. Any idea ?

Thanks a lot.