I'd like to be able to provide an import/export to csv feature for a specific Subscription (a subset of a Collection). However, I'm not sure at all where I should start. I assume that this has to be done server-side since they need to upload a file for the importing feature, so it probably involves a Meteor.methods function on the server which I call from the client. I'm not sure how you would return a file for download or temporarily upload one (for the import feature, I don't want to keep the file around).
Any ideas on the best way to approach this with Meteor?
I'm going to pretend this is the best way, but do check out CollectionFS, a Meteor package that implements file uploads, so a logged-in user can upload files, and file handlers, in this sense, a function or series of functions automatically run on an uploaded file.
For exports, you could pipe this through CollectionFS again, or you could use FileSaver.js to just directly serve the export file.
Related
I'm currently setting up an Akeneo (2.1) instance that needs to communicate with an e-commerce solution. I was wondering what the best practices are when it comes to importing and exporting data. The documentation kind of lacks in this; it tells how you can set it up, but I'm missing practical use cases here.
Here's what I'm thinking of:
I want our customer to be able to upload their images / CSV files using an FTP connection.
Akeneo should ideally only start importing when a mutation in this (FTP) destination folder is detected.
Exporting should only be done once or twice a day, and upon completing the archive should be transfered with (s)FTP to a different location
I'm currently having trouble on how to implement this flow in Akeneo. Because if I look at what comes out of the box I can come up with the following:
I can setup an FTP account that ends up in `app/uploads/product/` and allow the customer to upload to that location
Akeneo does not detect file system changes, so I can only setup a cronjob that tries to import every hour or something. The drawback of this approach is that Akeneo will copy the CSV file(s) every time to `app/archive/import`. If you have big CSV files this can cause for some increment in disk usage.
I can setup a cronjob to export twice a day, but again: Akeneo will create archives on every export, so `app/archive/export` will grow even bigger every day. Please note that my customer has 4GB+ assets (images, documents, etc.). Does Akeneo cleanup the `app/archive`-folder every now and then?
Every exported archive comes in a new folder (with an every incremented job number (`app/archive/export/csv_product_export/28/` for example)), so I'm kind of wondering how I can detect for this new folder and how I can trigger to uploading of the archive to the remote (S)FTP server after the export is complete.
I was just wondering how other people who work with Akeneo handled these challenges. I know I can write my own custom bundle and hook into a ton of events or write shell scripts that do lot of the magic for me, but I am wondering what Akeneo itself already offers regarding this subject.
Any thoughts / ideas / suggestions / experiences on this topic are welcome!
To answer your questions:
Akeneo doesn't need to have csv uploaded in the app/uploads/product/
folder. You can define the csv location in the import profile. That way you can use whatever location you want.
To import images, you need to zip them with the csv file (to see how the structure of the archive should look like, you can export some products with media on demo.akeneo.com)
Setting up a cronjob seems to be a good idea. If the disk usage is a problem, this cronjob could also clean the folder after the import.
To export twice a day, you can use the export builder to only export products that have been updated since last export (delta export). That way, you don't use too much space for nothing.
Again, the app/archive/export/csv_product_export/28/ path is only for internal use. This is a working directory used by Akeneo during the export (before zip for example) and the final file (csv or zip) is moved to the defined destination (in job configuration).
With all those informations, here is my recommendation:
Write a simple bash/php script to detect change in a folder and if there is one, move the file to another location and launch the import.
If you want to handle images, you can add to your script a way to generate the zip file with the good format
Then to export to your ecommerce, setup a cronjob to export every hours and export only new or updated products to the desired destination.
Another way would be to use the new REST API which is well documented here: https://api.akeneo.com/
I'm thinking about how to extend RT (and also with the IR extension, but I don't think this makes a difference) in regards to retrieving files from external sources (e.g. sftp) and adding them as attachments to tickets. I'm asking for suggestions of how I might go about this, as I've not used RT much and never programmed in Perl before.
I'm thinking of adding an input and button in the ticket to allow the user to provide a unique ID for the file and for them to be able to click when they want to retrieve the file from the external source, so not an automatic retrieval, unless it only does it once.
I'm thinking of creating a MakeClicky (http://requesttracker.wikia.com/wiki/MakeClicky) which creates a link to a cgi script (something like 'getfile(abc.txt)'), providing the ticket ID and the UID for the file. This script would then retrieve the file and post it as a comment/reply to the ticket. A couple of things to ask:
Are comments and replies to tickets really the only way to add an attachment? I read this somewhere but cant find the source now
How would I modify the existing ticket from a cgi script? Its on the same host, would I still need to use the REST api? Or can I just import the RT modules and add a attachment/comment/reply with the attachment without using the REST api?
The other option would be to create a scrip for on create/comment/reply that would search the contents of the ticket for an identifier for the file, retrieve the file and attach it.
I'm open to suggestions, unless one of these is a good way to do it!
TIA!
Importing categories as a CSV file is OK in tiki-wiki, But how to import categorized articles to the system. Tiki supports media wiki and word press importing, While my data base has another format.
Is there any module for CSV upload/import?
Is there any flexible migration-like script to import articles?
In case that both of answers are NO, would you please give me a clue to write down the proper code to import articles directly to data base.
I went through understanding database, But I think accessing to database directly should be my last choice!
For custom import jobs, you can use Tiki's profiles. The profiles are a YAML-based format. While it is not the primary use for them, it might be the easiest way to perform what you want to do.
Normally, you need to place the profile in a repository to execute it, but there is a developer option to load content from a textarea. You can simply prepare your YAML definition and paste it in there.
Categorizing elements through the database could be harder than it seems as many tables are involved.
I would like a better workflow for debugging uploaded SCOs. As things are, I must edit a file in the activity, repackage, upload, and test. Often, I just need to change a single line of code. It would be VERY nice to be able to edit that file, that line of code, on the server. So far, all I've found is that Moodle manages the files, so it seems impractical to locate and decipher the renamed files after upload.
Is there a way to configure Moodle so that it doesn't rename and relocated files in SCOs upon extraction? Actually, I'm open to any suggestions on the best, fastest workflow for debugging SCOs.
Problem background
Since Moodle 2.0, files are no longer stored on server in the conventional /this/is/the/path/to/my.file way. Instead, files are rehashed and stored in Repositories (i.e. spread all over the moodledata folder as a collection of seemingly random data). This increases security and cross-OS compatibility but complicates stuff for people who would like to simply upload a SCORM zip package via FTP. Here's more information on file handling in Moodle 2.0
Path to the soluton
Let's locate the file you want to update, then update it.
Run phpmyadmin, go to mdl_files table, find your file by name in the filename field (let's say it's portrait.jpg)
Look at the contenthash field, it'll look like abcde1234567890. This means your file is stored in moodledata/filedir/ab/cd/ folder under the name abcde1234567890.
Rename the updated portrait.jpg to abcde1234567890, upload and overwrite.
Go back to phpmyadmin and update the filesize field in record for portrait.jpg with the size of the updated file.
Obviously, this process can be automated. You'll have to write a script that allows you to upload a file, then it'll search for that file in mdl_files, save it to the correct folder and update all fields accordingly.
Alternative idea
Enable external package type (and also enable 'Update on every launch'). Go to Site administration / Plugins / Activities / SCORM and check the box down below. Now you'll be able to launch SCORM packages directly from another server, so Moodle won't mess with it. Of course, you can run in other (probably cross-domain related) problems.
Sergey's answer is very good, with one caveat:
In his example with the contenthash of abcde1234567890, the file is stored in the moodledata/filedir/ab/cd/ folder under the name abcde1234567890. Moodle uses the full contenthash to name the file.
I am developing a simple iPad application that should submit some text from a form to a .csv file. I could manage to update the .csv file which is saved locally in the documents folder on my computer. However, I need to keep the file on a server, probably download the file, append data, and upload it again (Export a bulk of data to the file on server). Any idea how I could do something like that?
I guess ftp might be the easiest way, see this question
your other options likely involve writing a server-side service to post data to.