The current "Move Note" dialog looks weird to someone who doesn't know what it does:

At least one info text should be added above the list of notebooks, so the user understands what he could do with this.

It looks like the ckEditor sometimes messes up with the styles, resulting in weirdly displayed elements. Test and check all kind of styles within the ckEditor.

I love this project. I am a Codeigniter programmer that was asked to find a local clone of Evernote and I stumbled on this.

I've looked around the site to see how I would install on a server and I don't find anything. Could someone give me a quick instruction?

Thanks!

So far Lato was being used on the web, until I found out that for example the Mozilla Firefox had issues loading the font files. However, I'm not sure, whether it's the perfect font to be used for this topic, though. And I don't know about the native clients as well. Maybe there's a better (in the sense of overall appearance and readability) font that could be used on the web?

Hi there. I'm VERY interested in this project, and am trying to get it set up on CentOS 7 (which will be documented and posted to my site). However I'm having a problem getting this set up correctly.

CentOS 7
PHP 5.6
mariaDB
Apache

I have paperwork downloaded at /var/www/html/paperwork, and have run php composer.phar install, which completes without error. I set up the database with the default (db/user/pass all paperwork), and then run php artisan migrate. Everything seems to install without error, apache and mariadb are running, and when I browse to http://server.domain/paperwork, it just shows the directory listing. I don't see any php or html files in the project root, so I'm not sure what page it's supposed to load?

Can you provide some assistance here?

Thanks!

Build APIs that allow sharing of notebooks with other Paperwork-users. The database layout is prepared for this feature and allows multiple many-to-many relations from notebooks to users, containing an "umask" column as well, which defines the users permissions on the related notebook. The values are identical to unix' chmod-values, with read adding 4, write adding 2 and ownership ("execute" in unix) adding 1 - resulting in the highest value of 7. For this purpose a tinyInt variable is being used, although a binary one (unsupported by Laravel) would have fit better.

However, the person creating and sharing a notebook would always have the umask set to 7, while invited people would be getting either 6 (read & write) or 4 (read only). I don't think it'll make sense to allow multiple notebook owners (7).

It should be possible to share notebooks with other Paperwork-users. Therefor, a dialog/page is needed, which lets the user invite someone else to a notebook and define his/her permissions.

Paperwork needs to be configurable to allow admins to integrate it with their existing LDAP/AD infrastructure. Therefor, the user authentication back-end needs to be adapted to use some sort of Laravel-Ldap extension.

It would be cool to have Paperwork translated in different languages. i18n functionalities are already available, we only need people who could translate the files contained in app/lang//*.php into other languages.

Each attachment upload should result in a newly created version of the note, in order to have a nicely browsable history.

Paperwork should soon switch from the HTTP Basic Auth it currently uses to OAuth2 while accessing the API. The tricky part probably is, that right now the front-end is using the API itself, but should further on be able to authenticate without OAuth.

After the common UI/common shapes are being defined, there needs to be a common look (and feel) of the mobile clients defined. A user that has used the Android client before, shouldn't have any issues using the iOS or WP client.

This issue depends on #35 and should be worked on hand-in-hand with #36.

Guidelines

Use elements from existing/competing apps so that people can easily adapt. (Evernote, Google Keep and Drive, Office 365 Mobile, Zoho)
There will be small variations between platforms, however, the position of the UI elements should be consistent. e.g. if the search box is located at the top of the screen on Android, it should be there on other platforms too. The exception to this is where 2 platforms have different UX convention.
We therefore aim to use common conventions that applies to most mobile platforms. (e.g. avoid hardware based menu button, iOS doesn't have that).

Hi,

First off, thanks for such an excellent project -- I think it's great, much-needed, and highly desirable for folks who love the Evernote concept but don't want someone else holding all of their data for them.

I've installed the latest release on my own server (CentOS 6.5), gotten it stood up, and everything seems to be running well. I've exported my Evernote ENEX file and tried importing it, which seems to be silently failing. All permissions seem to be set appropriately as I can create a new note and add an attachment, larevel.log is present in 'logs', et. al. Whenever I try to import the file, the settings page refreshes with the 'Language' tab as active and the 'User Interface Language' element and associated dropdown being colored in red. I even tried changing the ENEX file's extension to 'xml' thinking that might be the issue, but still no dice. The ENEX export file is only 89K -- certainly not large enough to violate any php.ini constraints, so I don't think that is the issue, either.

Neither laravel.log or my httpd's error_log seem to have anything pertaining to an error in them.

Thanks again for a great product,
Brad

No tests available. Write unit tests & introduce frontend tests.

As described here, some things still need to be added to the HTML structure of the layouts and some icons need to be included in order to allow users to add Paperwork (the mobile website) to their homescreens.

As the title says.

Actually it doesn't necessarily need to be a GitHub page - I could set up a WordPress or whatever, so we could build the new http://paperwork.rocks page on there. We just need some nice-looking theme (maybe similar to Paperwork's, even though it's not a final theme).

Here's an idea: How about Paperwork would implement a WebDAV interface using sabre (https://github.com/fruux/sabre-dav), which would allow working with Notes and Notebooks as they were files and folders?

Further thoughts: - How would attachments to notes appear? Would they appear at all?

• What would be the difference between a Notebook enclosing Notes and a Collection enclosing Notebooks only, from a filesystem point of view?
• Would this really provide a use for people?
• Would this push Paperwork too much into the "SharePoint" or "Alfresco" area?

Someone needs to think of a good concept for search. Here are some thoughts on that topic:

Should search be implemented right into the MySQL database or should an Elasticsearch (or whatever) be used? This decision would have a huge impact on the overall complexity of Paperwork. Therefor, maybe abstract the implementation allowing the administrator to decide, whether he'd like to stick with the simple MySQL setup or build a full-blown Elasticsearch solution?

Notes metadata has to be written into the search back-end. In addition, the tesseract OCR would need to write its parsing results into the search back-end as well, to allow the user to search for text that is contained in images he uploads.

Where on the back-end should search be implemented? Is it a task that is being triggered from within the API controller code? Or should it be run as a parallel background job through a job-queue?

How should the search API look like? How will it respond to search requests, if the request would take longer than usual to proceed?

A set of brand colors needs to be defined for Paperwork. The current colours were picked from http://www.google.com/design/spec/style/color.html#color-color-palette but I'm not sure if they fit the project, from an UI design aspect. The current logo was just something I drew to at least have a logo and surely could be done better.

This issue should be considered first, before working on #35, #36 or #38.

Each new user should see at least one pre-created and pre-filled notebooks with tips on how to use Paperwork. Currently, when a new user registers, he sees nothing but an empty interface.

It should be possible to move notes by selecting and dragging/dropping them onto the notebooks-sidebar.

According to some users, there are some issues with the currently in use webfont.

Each note in the listing may have a contextual menu, using this: https://github.com/ianwalter/ng-context-menu

There was @rguedes working on this, afaik, but I'm not sure whether he's still actively contributing here.

The user help should be written. The format for that is regular markdown with some specialities regarding URLs. Please refer to the current help page, to get more info.

"Invalid argument supplied for foreach() ApiTagsController.php line 10.
This happens when there are no tags in the database, in which case the $tagsArray argument is NULL."

Submitted by user.

The notes list (second column of the three: [notebooks list][notes list][note view]) needs to be extended to allow displaying an square image on the right quarter of the list entries.

Paperwork then should always display the first image it finds within a note in that image-square. By that, we give the users the ability to find the right now by checking the images within the notes list and, what's even more important, to actually find a note which only contains an image and no text at all.

Right now, there's a "languages" feature implemented, which allows the user to define, in what kind of languages the documents he usually uploads are written in. Under "Settings", each Paperwork user can select the languages he'd like Paperwork to support for his account.

This was being implemented, so that tesseract can be called with the according language option, which helps OCR.

Now, this is not the best way to solve this issue. If a user has "English" and "French" selected but one day uploads a document/image containing Greek words, these won't get parsed correctly by tesseract. Tesseract ran with the english and the french dictionary, but not the greek one.

Therefor, he would either need to enable "Greek" in his settings before uploading the document, resulting in tesseract running on ALL his documents to parse each with the greek dictionary as well (because, we don't know which documents is written in which language, right?).

The quick-fix here would be, to ask the user on each document upload, what language that image he's uploading is written in. So, if he photographs a letter from his french cousin and would like to upload that, he first needs to pick "French" in the document uploader. I personally don't like this solution.

Therefor, I'm wondering, if anybody knows, how language recognition or guessing could be done using tesseract?

This isn't something that needs to be done now, nor tomorrow, nor in a month - it's more of a backlog task that needs to be done someday, when Laravel 5 became available and got mature enough to be used in production.

Hey!

I'm currently testing some self-hosted evernote alternatives to find out, which one fits my needs the best and paperwork really does the (almost) best job!
In order to use it for "productivity" (i know...work in progress) I need to get rid of the "File a bug" window which is really annoying. I can't write a note with this note-taking app because there is this small window overlaying which prevents me from seeing what I'm writing - this doesn't makes sense to me :)

Please make it smaller, hide it in the help menu or somewhere else, but not this way! On my desktop's screen (23") it's ok, but on a 15" laptop - useless..

thanks in advance and for this beatuful app!

As the title says.

Tags are not being saved/processed.

After the common UI/common shapes are being defined, there needs to be a common look (and feel) of the desktop clients defined. A user that has used the Linux client before, shouldn't have any issues using the Mac or Windows client.

This issue depends on #35 and should be worked on hand-in-hand with #38.

Currently, the bootstrap-tagsinput by @timschlechter only creates tags when the user actually presses the "enter"-key. If he should just click somewhere else on the UI, the tag is not being created, remains pure text and therefor isn't being saved.

Now, this isn't something that needs to be fixed within Paperwork (but could be, although it would be quite a dirty hack), but Unfortunately the bootstrap-tagsinput project kind of fell asleep. Therefor I'd like some help here from anyone who's willing to contribute to Paperwork: Fix this issue and commit it to @timschlechter, so he can merge it into the official bootstrap-tagsinput repo. :-)

Hey!

are there any plans for implementing an export function in nearer future? Since I see me updating quite frequently, I want to backup my notes outside of the server environment.

best regards!

As far as possible.

A common UI with common shapes needs to be defined, which could be used on the web as well as with the native (mobile/desktop) clients, in order to give Paperwork an nearly equal look on each platform.

This issue depends on #33.

Using SJCL (http://bitwiseshiftleft.github.io/sjcl/) Paperwork could allow client-side, JavaScript note encryption, so that every note-content could be transferred and stored encrypted within the back-end.

This probably wouldn't work for all notes, like for example shared ones, but we could at least allow the user to specifically encrypt notes separately (not by default!), using a specific per-note-password. If the user then shares the note to someone, he could pass him along the password used for that note.

Integrating the ckeditor better into Paperwork by adapting its look & feel to its surroundings. However, this should be built in a way, that every theme is able to theme the ckeditor itself.

The mobile web-ui currently doesn't neither look nor work the way it should. While browsing from a smartphone, Paperwork should be acting a lot more like a native app. Not sure yet, what the best ui design for this would be, though. It even might be better to use Polymer (or something else) instead of pure Bootstrap to build the mobile UI, although this would result in having a separate mobile layout.

Good ideas, anyone?

Big images that are being included in notes should never show up wider than the view-frame they're displayed in and by that result the note to scroll horizontally. This needs to be fixed by using CSS styling within the note viewing-frame.

Autosave feature would be wonderful! That is one of the features of the evernote that I really like.

Having the option to create a nightly backup would also be very nice to have.

Technically, collections are possible. The thing is, that there is no way to create/edit these collections. Right now, it's impossible to move notebooks into others and by that form a new collection - because that's what collections actually are: Empty notebooks containing more notebooks.

The thing is, that collections can not contain any notes - only notebooks. So if someone would create two notebooks, fill one with notes and then "move" the second one into the former, all notes would become inaccessible. Therefor we need a clear way to create/edit collection and only allow a user to move notebooks into such.

Paperwork needs to hide the "ugly" AngularJS variables on page load, until there's real content inside of them. My quick try with adding ng-cloak didn't work the way I expected. Maybe some AngularJS expert knows the reason / a working way?

Write acceptance tests, maybe in mink/behat?

With document-uploads, content previews should be generated by OCR-ing the document.

The Angular.js code is yet pretty unstructured and not DRY enough. This should be cleaned soon.

Allow the user to tag notes by dragging a tag and dropping it into the notes list on the specific note.

To make it even more easy for users to start using Paperwork, something like a "guided tour through Paperwork" would be cool. This should be something similar to what other services do: A message right at the beginning, asking the user whether he'd like a guided tour. If the user accepts, bubble-tooltips should pop up above the UI, showing the user the most important features of Paperwork. These tooltips should appear one after another and advance as soon as the user clicks/taps.