[Mayan EDMS: 2671] This forum is now on read-only mode please use https://forum.mayan-edms.com. Thank you.

[Roberto Rosario]

This forum is now on read-only mode please use 
https://forum.mayan-edms.com. Thank you

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2670] Versions 3.0.2 and 3.0.3 released

[Roberto Rosario]

These releases fixed a few issues and close three possible security issues. 
Users are encouraged to upgrade.

*Docker install script*
   
   - Default to verbose.
   - Increase startup timer from 5 to 10 seconds to give more time to users 
   to examine the settings of the installation to be performed.
   - Add support for configuring the PostgreSQL port. Useful when there are 
   existing PostgreSQL installations.
   - Docker install script: Detect if Docker installed and provide help 
   text if not.

*Documentation*
   
   - Add deployment step that configures Redis to discard unused task data 
   when it runs out of memory. Redis is only used for volatile data therefore 
   configuring it to discard data doesn’t affect functionality but increases 
   response time and reduced memory consumption.
   - The default timeout for gunicorn has been increased from from 30 to 
   120 seconds.
   - The code statistics and pending work chapters have been removed from 
   the documentation. The pending work list has been divided into a pending 
   and a planned feature list and moved to the new Wiki at wiki.mayan-edms.com

*Program code*
   
   - Index app: Add natural key support to the Index model.
   - Mailer app: Add natural key support to the mailer app.
   - Cabinets: Redirect to the cabinet list view after creating a new 
   cabinet.
   - Converter app: Fix crop transformation argument parsing.
   - Converter app: Add error checking to the crop transformation 
   arguments. Thanks to Jordan Wages (@wagesj45) for the report and 
   investigation on the issue. Closes GitLab issue #490
   - Common app: Fix post login redirection to honor the ?next= URL query 
   string argument. Thanks go to K.C. Wong (@dvusboy1). Closes GitLab issue 
   #489.
   - Sources app: Update dropzone.js’ timeout from 30 seconds to 120 to 
   allow upload of large files on slow connections.
   - Documents app: Display error when attempting to recalculate the page 
   count of an empty document (document stub that has no document version).
   - Appearance app: Include querystring when force reload of a bare 
   template view.
   - Documents app: Fix trashed document count and document page count 
   swapped dashboard icons.
   - Documents app: Rename the multi document download link from “Download” 
   to “Advanced download” for consistency.
   - Appearance app: Add support for hiding a links icon. Hide all object 
   menu links’ icons.
   - Documents app: Hide the title link of documents in the trash.
   - Workflow app: Define a redirection after workflow actions are edited.

*Security*
   
   - Appearance app: avoid setting window.location directly to avoid 
   exploit of cross site scripting. Thanks to Lokesh (@lokesh1095) for the 
   report and solution. Closes GitLab issue #494.
   - Cabinets app: Escape cabinet labels to avoid possible exploit of cross 
   site scripting. Thanks to Lokesh (@lokesh1095) for the report and proposed 
   solutions. Closes GitLab issue #495.

*Project*

Due to the many issues with the current Google Group mailing list product, 
the project's mailing list is being retired and will be placed in read only 
mode in the near future. A new forum platform has been made available at 
https://forum.mayan-edms.com


-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2669] New forum is online

[Roberto Rosario]

After trying out several solutions we've settled on phpBB for the new forum.

The address is https://forum.mayan-edms.com

It is configured to the best of our limited knowledge so if you find 
something wrong or misconfigured please let's us know to fix it.

At the moment there are two areas: one for news and one for general 
discussions. In the future we might create more areas to better group 
ongoing conversations.

This current mailing list/forum will be set to read only in the near future 
and left only as a reference.

Thank you.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2664] Re: Send email on workflow transition

[Roberto Rosario]

I think I misread. You want the workflow to trigger when some add a 
document comment? If that's the case then yes, that is already supported 
and is done via "Transition triggers". You can connect a document event to 
a workflow transition. Screenshots attached.

On Wednesday, August 8, 2018 at 5:46:53 PM UTC-4, Roberto Rosario wrote:
>
> The first one is already in the published pending work list. And should be 
> straight forward. Might be able to push it up to add in the next release.
>
> The second one is harder. Right now the worflow doesn't have support for 
> user input during execution. This is something we want to add but requires 
> significant refactor. We need to add support for workflow forms and for 
> workflow contexts (a means to store values in a workflow). What I can do is 
> push up one or two of this requirements so that they can be tested by the 
> community in upcomming releases and pave the way for reviewer style feature 
> you mention.
>
> On Thursday, July 26, 2018 at 4:29:47 AM UTC-4, Dexter wrote:
>>
>> Hi All,
>>
>> Is it possible to setup actions on workflow transition, like send email 
>> to author ?
>> Is it also possible to setup actions when someone (reviewer) adds a 
>> comment to the document ?
>>
>> Thanks
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2663] Re: Socket error while uploading document

[Roberto Rosario]

Looks like the webserver is not being able to communicate with the Mayan 
WSGI application. The communication can happen via localhost or a unix 
socket. Check the documentation of the webserver to see how to specify 
which socket type to use and match that to the socker type you are using in 
the WSGI application.

Mayan moved away from Apache to simplify the installation process.

Here are some examples of deployments using 
Apache: https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/modwsgi/


On Tuesday, July 31, 2018 at 9:22:06 AM UTC-4, vsolvs...@gmail.com wrote:
>
> hi,
>   I have configured maya-edms in apache on ubuntu 16.04. The project is 
> working fine, but while uploading the file 
>I getting an error -->  ""Error executing document upload task; 
> [Errno 111] Connection refused, ""
>  Please help me to solve this problem
> thanks in advance.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2662] Re: upgrade to 3.0, sqlite questions

[Roberto Rosario]

Thanks!

Things are finally a bit better. You can read about some of the gymnastics 
we've had to do to be able to continue our daily lives in the information 
age :) 

https://medium.com/@siloraptor/solar-powered-microservers-for-a-post-hurricane-maria-puerto-rico-ca83027d20ac

Electric service is more stable now (one blackout every week or two weeks), 
but I still continue modifying hardware to run on DC off of the solar 
system as a precaution.

Yes, Eric and Michael have been doing a ton of work adding new features and 
even code from their commercial version (they have one install that gets 
10,000 new documents per day). Their experience scaling Mayan has been very 
valuable. 

For the database conversion we are making use natural keys which use a 
combination of fields instead of a sequencial number to guarantee that a 
dumped data from a model is reconstructed exactly the same in a new 
database. We also added an experimental "convertdb" console command that 
handles almost all of the process automatically. The main problem we have 
right now is with the package django-celery, a third party package. It 
doesn't support natural keys. We submitted a patch 
(https://github.com/celery/django-celery/pull/552) but the last release was 
in November 2017. If there is no new release by the time we plan to make 
our we going to have to come up with another solution (monkeypatch, release 
our fork as a PyPI package or other).

We are giving the database conversion issue top priority and have an almost 
complete solution in place for the next release. We are still dependant on 
a new release of django-celery and on users that have allowed us to use 
their database so we can test against real data. Our patches have a high 
success ratio and this will continue improving on subsequent releases.

On Saturday, July 28, 2018 at 6:16:14 PM UTC-4, Douglas Van Es wrote:
>
>
> first, great work merging NG and mayan guys! i really appreciate the huge 
> amount of work you have done, and it is amazing that roberto has been 
> able to continue development in light of the destruction the hurricane 
> brought to his country. and the development done by the ng team and those 
> that have joined roberto on a more permanent basis is fantastic as well! 
>
> now. how do i dump and import my sqlite db? 
>
> i see the earlier posts on the matter, and it seems i will (or may) need 
> to serialize the data before i can import. but this process is incomlete? 
> with a sqlite db with only some 16000 documents, will i really have 
> duplicate #'s? 
>
> i am unsure if the examples others have posted regarding upgrading are 
> appropriate to my install, as it seems nobody who has posted is running 
> mayan in the same way i do. 
>
> i simply run mayan in a docker container, per the documentation! lol. 
>
> i have the sqlite db data in a persistent docker volume. i created the 
> volume like so: 
>
>   # docker volume create --name mayan_media --opt type=none --opt 
> device=/[PATH_TO_PERSISTENT_DATA] --opt o=bind 
>
> i initialize the container: 
>
>   # docker run --rm -v mayan_media:/var/lib/mayan -v mayan_settings:/etc/ 
> mayan mayanedms/mayanedms mayan:init 
>
> then when i start mayan i do it like this: 
>
>   # docker run -d --name mayan-edms --restart=always -p 80:80 -v 
> mayan_data:/var/lib/mayan -v /[PATH]/invwatch:/[PATH]/invwatch -v /[PATH]/ 
> invstaging:/[PATH]/invstaging mayanedms/mayanedms:2.7.3 
>
> what will i have to do to migrate my sqlite db to postgresql? and is that 
> the simplest/recommended way, or should i use mysql? 
>
> thanks in advance! 
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2661] Re: how to create metadata?

[Roberto Rosario]

After you create the metadata type and associate it to a document type as 
you did. You use the "Add metadata" button in the document view first 
before attempting to edit the metadata which still doesn't exists for the 
document. If you try to edit a non existing metadata it is supposed to 
redirect you to add it first. It seem in your case this code failed and 
showed an error instead. Please provide a screenshot of the error in 
console so we can pinpoint what failed and fix it. Thanks.

On Wednesday, July 25, 2018 at 6:05:38 AM UTC-4, vsolvs...@gmail.com wrote:
>
>  I have document type by name "invoice".
> I want to link metadata with "invoice". so i created metadata by name 
> "invoice_data" and label "invoice_data" and i left default and lookup empty.
> and i set "invoice" as optional in metadata-type  ,Then I tried to add 
> particular file in "Invoice" to metadata I get an error--"
>
> list index out of range
>
> "
> Please guide me to create a metadata . thanks in advance..
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2660] Re: PROJECT_TITLE setting in 3.0.1?

[Roberto Rosario]

We added a new configuration option to make this easier for users. Starting 
from the next version you can change is via the  COMMON_PROJECT_TITLE 
setting option 
(https://gitlab.com/mayan-edms/mayan-edms/blob/versions/next/mayan/apps/common/settings.py#L68)

We are also working on an setting UI update to allow changing these 
settings from the UI. Users will still need to restart their Mayan install 
but no console editing will be needed (this feature about 80% done).

On Wednesday, July 25, 2018 at 12:54:13 PM UTC-4, LeVon Smoker wrote:
>
> Figured this out...
>
> I have a custom app for my Mayan overrides. In the 'ready' function in my 
> apps.py, I added a line:
>   mayan.__title__ = 'My Fancy Title'
>
> Of course at the top of apps.py, you'll need:
> import mayan
>
>
>
> On Wednesday, July 25, 2018 at 9:07:38 AM UTC-4, LeVon Smoker wrote:
>>
>> I see where I can make a hard-coded change in the templates, but I don't 
>> want to touch the original source. Is there a way for base.html to be 
>> overridden?
>>
>> On Wednesday, July 25, 2018 at 4:54:53 AM UTC-4, vsol...@gmail.com wrote:
>>>
>>> check the script in base.html 
>>>
>>> On Tuesday, July 24, 2018 at 7:45:35 PM UTC+5:30, LeVon Smoker wrote:

 Is there no longer a way to set the title of the site in 3.0.1? In 
 2.7.3 I could set the PROJECT_TITLE setting to something that included my 
 agency name.

 (I'd rather not hack the source...)

 LeVon Smoker

>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2659] Re: Help with Access Control

[Roberto Rosario]

1. Create a new user group. [Setup] -> [Groups], [Actions] -> [New]
2. Add yourself to the new group. Example: "Personal"  [Setup] -> [Groups] 
-> [Personal] -> [Users]
3. Create a new role. Example "Personal" [Setup] -> [Roles], [Actions] -> 
[New]
4. Add your group (Personal) to the role (Personal).  [Setup] -> [Roles] -> 
[Groups]
5. Go to the Personal document type and click on ACLs   [Setup] -> [Roles] 
-> [Personal] -> [ACLs]
6. Create a new ACL and choose your role (Personal) and grant it all the 
permissions you need/want.  [Actions] -> [New ACL]

Upload a document using the "Personal" document type and check as another 
user or a test user to make sure the setup worked.

On Friday, August 3, 2018 at 4:56:12 PM UTC-4, Ray Hendricks wrote:
>
> Right now I have a document type of Default and all users have access to 
> these files.  I would like to have a document type of Personal and have me 
> be the only one that can view these.  I've tried setting this up with 
> Types, roles, groups, ACL, etc. but honestly, I'm lost and can't get it to 
> work.  Is anyone willing to walk me through the process of setting this up?

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2658] Re: Customize the search form

[Roberto Rosario]

"I overrode (is that a word?)" I'm not a native speaker, my guess is as 
good as yours :D

Thanks for sharing your customization. I'll see if we can add some of your 
changes so you don't have to rewrite all from scratch on the next update.

On Thursday, August 9, 2018 at 2:51:06 PM UTC-4, LeVon Smoker wrote:
>
> Using a custom app, I overrode (is that a word?) the appearance/home.html 
> template to point at my own url on the Advanced button ({% url 
> 'my_overrides:search_advanced' search_model='documents.Document' %}). From 
> there it was creating custom versions of AdvancedSearchForm, 
> AdvancedSearchView, and ResultsView to get what I wanted. My version of 
> AdvancedSearchForm adds a ModelMultipleChoiceField which provides an 
> autocomplete way to find specific documents.
>
> In my AdvancedSearchForm, I was able to change the label on a field - 
> Label - to Name (users were confused - "where's the document name?")
>
> On Wednesday, August 8, 2018 at 5:11:44 PM UTC-4, Roberto Rosario wrote:
>>
>> Autocomplete is possible but will require a new API to return the top 
>> result values so that a smart widget like Select2 could display them. 
>> Possible but requires code changes. 
>>
>> What do you mean by "change the field labels"? Can you expand on this? 
>> This one might be simpler to implement.
>>
>>
>> On Tuesday, July 31, 2018 at 2:17:45 PM UTC-4, LeVon Smoker wrote:
>>>
>>> Is there a good way to do this to...
>>> - change the field labels
>>> - add a custom search widget (autocomplete)
>>>
>>> As always, I don't want to hack the original source code...
>>>
>>> Thanks.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2657] Re: how to configure celery in apache ?

[Roberto Rosario]

Check step #13 of the basic deployment guide in the Wiki 
here: https://wiki.mayan-edms.com/index.php?title=Basic_deployment

You need to install supervisor and then create a file in 
/etc/supervisor/conf.d to run the Celery workers and task scheduler.

Care to share your Apache configuration file?

On Monday, August 13, 2018 at 4:51:26 AM UTC-4, vsolvs...@gmail.com wrote:
>
>  I had configured mayan-edms in apache. I use "./manage.py celery worker 
> -l DEBUG" to run celery. how to I configure  celery worker in supervisor. 
> thanks in advance
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2656] Re: Filtering a document queryset on the ACL/role name

[Roberto Rosario]

That is a fantastic idea and a good candidate for a MERC proposal 
(http://docs.mayan-edms.com/en/stable/mercs/)

Some tip when working with the permission system.

These don't directly apply to the mountindex command since we don't have a 
way to know which user is accesing the mounted index. But for the normal 
web stuff here is how to filter data:


Don't specify the role label or the permission name, the role label might 
get updated by another user and the permission name could change between 
releases (unlikely but possible). Use the filter_by_access method of the 
AccessControlList manager.

filtered_queryset = AccessControlList.objects.filter_by_access(
permission=permission_document_view, user=self.request.user,
queryset=queryset
)

The permission is obtiained by importing from the .permissions.py module 
found in each app. This code here filters the queryset of documents and 
allows only those for this the user currently logged (obtained from 
self.request, the HTTP request object). The filter code first check if the 
use has the global permission assigned (document view for all documents). 
And then iterates over all the groups and roles to which the user belongs 
as an user can inherit the permission by subscription to a role or an ACL. 
If the are no permissions in any of the user's roles, the queryset is 
returned empty.

If you just want to know if an user can or cannot to an action use the 
"check_access" method. 

AccessControlList.objects.check_access(
permissions=permission_document_view, user=request.user,
obj=self.document
)

If works in the same way. First check for a global permission and then for 
the permission in each role and then for the ACLs. If not permission is 
found the method raised the PERMISSION_DENIED expection and the user 
interface redirects to the insufficient permission template.

It would be great to find a way to find which OS user is trying to access a 
document from a mounted index and correlate with the Mayan user in the 
database to be able to do dynamic filesystem filtering.


On Friday, August 17, 2018 at 9:59:23 AM UTC-4, LeVon Smoker wrote:
>
> And it would be neat to have some document info/metadata be made available 
> as extended file attributes through listxattr and getxattr...
>
> On Thursday, August 9, 2018 at 2:32:56 PM UTC-4, LeVon Smoker wrote:
>>
>> I ended up creating my own version of the mountindex management command 
>> in a custom app
>>
>> On Wednesday, August 8, 2018 at 5:16:01 PM UTC-4, Roberto Rosario wrote:
>>>
>>> Makes sense to filter documents. An ideal solution would be to 
>>> correlation the OS username to a Mayan user to inherit the permission. Or 
>>> in the mean time a filtering method via the mountindex command line to 
>>> avoid needing to change the code. Your question brings an interesting 
>>> proposition to the mountindex feature.
>>>
>>> On Tuesday, July 31, 2018 at 8:52:01 AM UTC-4, LeVon Smoker wrote:
>>>>
>>>> I figured it out eventually. In the 
>>>> mirroring/management/commands/mountindex.py, I added...
>>>> acls = AccessControlList.objects.filter(role__label='My Role', 
>>>> permissions__name='document_view')
>>>> queryset = queryset.filter(acls__in=acls) 
>>>>
>>>>
>>>>
>>>> On Friday, July 27, 2018 at 10:12:21 AM UTC-4, LeVon Smoker wrote:
>>>>>
>>>>> How can I do this? I intend to make my own version of the mountindex 
>>>>> command that would allow filtering documents based on a role. I assume 
>>>>> it's 
>>>>> like filtering on a Generic Relation, but I can't figure it out...
>>>>>
>>>>>
>>>>> https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericRelation
>>>>>
>>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2648] Re: Great SW - but there is a few things I can't figure out

[Roberto Rosario]

The issue tracking the Workflow assignment/inbox 
feature: https://gitlab.com/mayan-edms/mayan-edms/issues/471

The decision blocking implementation is if whether to allow assigment to an 
user, group or role. Also should this assignment be "free for all" meaning 
any user in the system or to a restricted list defined somehwere else like 
in the workflow definition itself. We need to come up with a solution that 
works for 95% of cases and not just for document approval type workflows. 
This is the main point we are trying to define to start working on this 
feature, everything we've figured out.

On Wednesday, August 15, 2018 at 4:22:19 PM UTC-4, Roberto Rosario wrote:
>
> Thanks!
>
> 1- The way notifications work in Mayan is via subscription to events. The 
> user must be subscribed to the document's events to receive notification 
> about changes to a document. We've discussed the possible implementation of 
> a "workflow inbox" to received a list of pending workflows to attend by 
> assignment. If we finish the specifications of this we might start working 
> on it soon.
> 2- At the moment this is not possible. If we implement the workflow inbox 
> feature, the it will possible to add a multi select as it is done in the 
> document list view for example.
> 3- I'm not sure I understand the question. Can you expand on it?
>
>
>
> On Monday, July 16, 2018 at 7:07:43 AM UTC-4, Axel Juhl wrote:
>>
>> Thank you this is great open source software :-)
>> Testing latest release (docker 3.01) there is a few things I can't figure 
>> out:
>> 1) How to select a specific user or group in a workflow to approve a 
>> certain state and how to get him/she notified
>> 2) how to mass approve documents in a workflow and
>> 3) how to write an index filter which can convert metadata to numerical 
>> representations for computation (they are all strings) - do I have to 
>> register a custom django filter ?
>> Br Axel
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2647] Re: Document preprocess on upload

[Roberto Rosario]

I understand better now. It would just be a case of adding support for 
previewing LaTeX files in the converter app. Can you provide some sample 
LaTeX files (no confidential or private information) or point to links of 
LaTeX used for testing rendering software? A list of software or command 
used for generating PDFs out of LaTeX files will be useful too as we don't 
have experience with LaTeX files.

On Wednesday, August 8, 2018 at 6:07:12 PM UTC-4, Dexter wrote:
>
> Thanks. Your idea seem to do the what is expected but has the following 
> major drawbacks:
> - Creating a new doc will destroy the link between the "source" and the 
> created PDF
> - By deleting the original document, we can no longer have access to the 
> source. This is problematic for the review process: in order to change the 
> document, we need to download the source, modify it and upload a new 
> version in source form. As the link between source and PDF is lost, the 
> newly created PDF from the modified source will not be a new PDF version 
> but a new document
>
> What I was thinking of is much simpler: You're generating pictures from 
> uploaded documents for the preview. In fact, you upload a PDF and preview 
> pictures of pages. This time you would upload a LaTeX and still preview 
> pictures. You just need to recognize that this is a LaTeX document and run 
> the generator locally. This will either be hardcoded in the source (like 
> now for PDFs, OO documents, ...) or offer a mean of launching PDF 
> generators for unknown types.
>
> Thanks
>
> On Thursday, July 26, 2018 at 12:14:41 PM UTC+2, Dexter wrote:
>>
>> Hi All,
>>
>> Is it possible to perform a preprocess on uploaded document ?
>>
>> The idea is that we would like the sources of the documents to be 
>> uploaded ( for example LaTeX files and projects), and make Mayan run the 
>> compiler and generate a PDF. This PDF will be what is shown in the preview.
>>
>> Without this we must upload the PDF version, and find another system to 
>> store the sources. We don't like the idea of using two tools to store 
>> documents
>>
>> Thanks
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2646] Re: Use document's metadata for filename (Quick Labels)

[Roberto Rosario]

Support for renaming a document via the workflow was added. 

We added a sample workflow to describe your scenario as it has been 
requested a few times. This is what we ended up with:

A workflow of two states and two transitions is need. The first state 
renames the document based on a template that has access to the document's 
metadata. The renaming of the document triggers a transition to a second 
state. The workflow sits idle in this second state until a metadata is 
edited. Any metadata update triggers the workflow to transition to the 
first state where it is renamed again. This allows the document to be 
renamed upon upload and if the metadata changes later on.

Release date is uncertain as there are still 80 items in the shortlist for 
this version and we are still working on the SQLite to PostgreSQL database 
conversion command (this is one is the top priority for the next version).

On Thursday, August 9, 2018 at 3:32:59 AM UTC-4, Martin Kinitzki wrote:

> Thanks for the answer! Looking forward to the next version. Any rough 
> estimate on the release cycles?
>
> Am Mittwoch, 8. August 2018 23:10:00 UTC+2 schrieb Roberto Rosario:
>>
>> We've been testing ideas for something like this. Unfortunately it would 
>> only work once the document is uploaded and available in the system. This 
>> is because during the upload wizard the document still doesn't exist and 
>> cannot be referenced by a template variable like {{ document...}}. 
>> Templated quick labels would only work after the document is uploaded by 
>> going to the document properties edit view. 
>>
>> A related feature we are working on right now is allowing the renaming of 
>> a document via workflow actions. This way a document is uploaded and when 
>> the workflow triggers a state (initial or otherwise) the rename action is 
>> executed. In this format a templated label field would have access to all 
>> of the document's properties including metadata values. This is in the 
>> works right now and very possible to be included in the next release 
>> (version 3.1).
>>
>>
>> On Wednesday, August 8, 2018 at 8:59:57 AM UTC-4, Martin Kinitzki wrote:
>>>
>>> Hey guys,
>>>
>>> is there any way to use a document's metadata (I added a metadata field 
>>> for suppliers) for renaming documents via quick label? I tried it with {{ 
>>> document.metadata_value_of.supplier }} with supplier being my metadata 
>>> field. Unfortunately it takes {{ document.metadata_value_of.supplier }} as 
>>> a String. 
>>> The reason is that I would like to have the filenames in that way: 
>>> *-MM-DD 
>>> Invoice Supplier*
>>>
>>> Thanks in advance.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2645] Re: Great SW - but there is a few things I can't figure out

[Roberto Rosario]

Thanks!

1- The way notifications work in Mayan is via subscription to events. The 
user must be subscribed to the document's events to receive notification 
about changes to a document. We've discussed the possible implementation of 
a "workflow inbox" to received a list of pending workflows to attend by 
assignment. If we finish the specifications of this we might start working 
on it soon.
2- At the moment this is not possible. If we implement the workflow inbox 
feature, the it will possible to add a multi select as it is done in the 
document list view for example.
3- I'm not sure I understand the question. Can you expand on it?



On Monday, July 16, 2018 at 7:07:43 AM UTC-4, Axel Juhl wrote:
>
> Thank you this is great open source software :-)
> Testing latest release (docker 3.01) there is a few things I can't figure 
> out:
> 1) How to select a specific user or group in a workflow to approve a 
> certain state and how to get him/she notified
> 2) how to mass approve documents in a workflow and
> 3) how to write an index filter which can convert metadata to numerical 
> representations for computation (they are all strings) - do I have to 
> register a custom django filter ?
> Br Axel
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2644] Re: Cannot access Mayan-edms on Digital Ocean using Docker

[Roberto Rosario]

Do a docker logs -f  to examine the logs for errors. Also 
the container takes some time to start as it performs database migrations 
and downloads the javascript files for the frontend. It might take between 
30 seconds to 2-3 minutes depending on the hardware and internet connection 
speed.

On Friday, August 10, 2018 at 12:37:59 AM UTC-4, Troy Borja wrote:
>
> Hello,
>
> I created a 4GB Ubuntu 16.04 droplet on DigitalOcean and installed 
> Mayan-edms v3.0.1 using the Docker image instructions. Installation worked 
> and the docker containers for mayan-edms are running. When I try to access 
> Mayan-edms using the IP address of the droplet, the browser says the site 
> is unreachable.
>
> Is there anything else I have to setup to gain access to Mayan-edms?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2631] Re: Migration error using MySql db

[Roberto Rosario]

Which version or fork of Mayan are you using? This error is typical of 
MySQL when indexing text fields. Mayan doesn't index text fields. All 
indexed fields are of CHAR 255 type.

On Tuesday, July 17, 2018 at 8:40:05 AM UTC-4, vsolvs...@gmail.com wrote:
>
> I configured project using Django server. I had added the required 
> libraries based on requirement. when I tried to migrate Django using Mysql 
> server, I get error: 
>
> "django.db.utils.OperationalError: (1170, "BLOB/TEXT column 'value' used in 
> key specification without a key length")"
>
> When I searched this error, I found  -->MySQL error: key specification 
> without a key length 
> .
>  but I occur error while migration. 
>
> mysql version - 5.7.20
>
> please help me to find the problem. thanks in advance
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2630] Re: Migrate sqlite DB to postgres

[Roberto Rosario]

We are working on adding and official method to convert the database use 
from SQLite to another like Postgres. Some changes already made it to the 
next version branch and we've execute successful migrations with some large 
document databases.

We have included a "convertdb" command 
(https://gitlab.com/mayan-edms/mayan-edms/blob/versions/next/mayan/apps/common/management/commands/convertdb.py)
 
and will available in the next version.

On Tuesday, July 24, 2018 at 1:33:08 AM UTC-4, Nicholas Loscalzo wrote:
>
> Unfortunately running mayan-edms.py dumpdata from inside the docker 
> container gives me [CommandError: Unable to serialize database: unable to 
> open database file and I'm unsure what's going on.  Is it because Mayan 
> has a lock on the database file ?
>
> The warning messages against using SQLite got me a bit scared, so I'd like 
> to move over to Postgres from SQLite, but I already have a good number of 
> documents in Mayan.  In the worst case scenario, can the database be 
> re-built from scratch if I move the document cache folder into place ?  In 
> that scenario I'd understand if it lost the cabinets, etc
>
> Thanks !
> -Nick
>
> On Friday, July 6, 2018 at 4:43:11 PM UTC-4, Roberto Rosario wrote:
>>
>> The method that most approaches a migration solution is using dumpdata 
>> and loaddata (
>> https://docs.djangoproject.com/en/2.0/ref/django-admin/#dumpdata) (
>> https://docs.djangoproject.com/en/2.0/ref/django-admin/#django-admin-loaddata).
>>  
>> dumpdata create a platform independent JSON file of the data using 
>> serialization. This method requires that support for natural keys is added 
>> to all database models (
>> https://docs.djangoproject.com/en/2.0/topics/serialization/#topics-serialization-natural-keys).
>>  
>> This process was started but is not yet complete.
>>
>> If you tried to do a dumpdata/loaddata migration and it failed, reporting 
>> the apps that failed will help us complete support for this and provide an 
>> official migration process.
>>
>> On Friday, July 6, 2018 at 7:39:01 AM UTC-4, Jay 1972 wrote:
>>>
>>> Hi,
>>>
>>> I'm running in the same issue, that I'm using the SQLite3 DB and getting 
>>> this message on every site in the WebUI.
>>> I'm wondering if there is a standard routine to migrate the DB from 
>>> SQLite3 to PostgreSQL, mySQL or MariaDB?
>>> Maybe other users already done so and have a migration path or useful 
>>> hints, which migration works best?
>>>
>>> Kind regards,
>>> Michael
>>>
>>> Am Donnerstag, 5. Juli 2018 00:51:58 UTC+2 schrieb Roberto Rosario:
>>>>
>>>> Django itself doesn't provide a method for direct database migrations. 
>>>> What you tried to do is the recommended procedure by the Django project. 
>>>> However for it to work there are some stuff that need to be added to the 
>>>> models so they use unique natural keys and not numeric primary keys which 
>>>> can be repeated (which is the error you encountered). We started adding 
>>>> natural keys a while back but that work is unfinished. What apps reported 
>>>> repeated keys when you did the loaddata command? We can try to work on 
>>>> those to see if the migration finishes without error.
>>>>
>>>> On Tuesday, July 3, 2018 at 5:19:57 PM UTC-4, hubertu...@5x2.de wrote:
>>>>>
>>>>> I have updated mayan to 3.0 via docker and I am getting the message, 
>>>>> that i should not use sqlite in production. But when I start the docker 
>>>>> image with postgresql, the database is empty. i assume, mayan will not 
>>>>> automatically convert any existing sqlite databases.
>>>>> I tried to export the sqlite data and import on the posgresql 
>>>>> installation with mayan-edms.py loaddata , but im getting errors 
>>>>> about duplicat keys, etc. (i did a mayan-edms.py flush   before.).
>>>>>
>>>>> How do I properly migrate my database from >3.0 mayan db.sqlite3 to 
>>>>> posgresql?
>>>>>
>>>>> --
>>>>> Hubi
>>>>>
>>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2629] Re: New to Mayan, trying to change settings, getting manage.py error

[Roberto Rosario]

Try adding an empty __init__.py to mayan.media and to 
mayan.media.mayan_settings so that mysetting is importable
You can use the touch command:

touch /opt/mayan-edms/mayan/media/__init__.py
touch /opt/mayan-edms/mayan/media/mayan_settings/__init__.py

If you installed version 3.0, the initialsetup command should have created 
these for you.

On Wednesday, July 25, 2018 at 1:44:35 PM UTC-4, Adam Kaney wrote:
>
> I just recently installed Mayan doing the advanced install on Ubuntu 
> 18.04. 
>
> I'm trying to change the storage locations.
>
> I created a mysettings file per the instructions on the Mayan website:
>
> #!/opt/mayan-edms/bin/python
> from mayan.settings.production import *
>
> DOCUMENTS_CACHE_STORAGE_BACKEND_ARGUMENTS='{location: 
> /media/145mayan/document_cache}'
>
> DOCUMENTS_STORAGE_BACKEND_ARGUMENTS='{location: 
> /media/145mayan/document_storage}'
>
> When I run python manage.py runserver 
> --settings=mayan.media.mayan_settings.mysettings
>
> I get the error: python: can't open file 'manage.py': [Errno 2] No such 
> file or directory
>
> I'm still new to this, so hopefully it is just something simple that I'm 
> missing
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2628] Re: Send email on workflow transition

[Roberto Rosario]

The first one is already in the published pending work list. And should be 
straight forward. Might be able to push it up to add in the next release.

The second one is harder. Right now the worflow doesn't have support for 
user input during execution. This is something we want to add but requires 
significant refactor. We need to add support for workflow forms and for 
workflow contexts (a means to store values in a workflow). What I can do is 
push up one or two of this requirements so that they can be tested by the 
community in upcomming releases and pave the way for reviewer style feature 
you mention.

On Thursday, July 26, 2018 at 4:29:47 AM UTC-4, Dexter wrote:
>
> Hi All,
>
> Is it possible to setup actions on workflow transition, like send email to 
> author ?
> Is it also possible to setup actions when someone (reviewer) adds a 
> comment to the document ?
>
> Thanks
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2627] Re: Document preprocess on upload

[Roberto Rosario]

This is an interesting concept. Since Mayan was originally made to be used 
in government and legal setting, one of the philosophies was to keep the 
uploaded document intact. This is to preserve the chain of evidence. 

In this case the possible solution we've come up with is to add new 
workflow actions to create a new document (PDF) based on a previously 
uploaded document (LaTex one) and then delete the previous document. This 
way there is a log of how the PDF was created and the upload process 
doesn't need to be customized. For this three workflow actions need to be 
created: A document delete action, one to call an external binary and 
another to the upload a new file as a document.

More discussion is needed but just letting you know how far we are in the 
brainstorm.

On Thursday, July 26, 2018 at 6:14:41 AM UTC-4, Dexter wrote:
>
> Hi All,
>
> Is it possible to perform a preprocess on uploaded document ?
>
> The idea is that we would like the sources of the documents to be uploaded 
> ( for example LaTeX files and projects), and make Mayan run the compiler 
> and generate a PDF. This PDF will be what is shown in the preview.
>
> Without this we must upload the PDF version, and find another system to 
> store the sources. We don't like the idea of using two tools to store 
> documents
>
> Thanks
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2626] Re: Remove transformations from 1800 documents

[Roberto Rosario]

This was most likely caused by the automatic orientation detection. This 
feature now defaults to disable since PDF are not always compliant. In 3.0 
it is possible to select all the document in a page (40) and delete the 
transformations. A entry can be added to the "Tools" menu to clear all 
transformation in the system. In the meantime the only solution would be to 
launch a Python shell inside the Docker instance using:

docker exec -ti  /bin/bash

The launcher a Python shell connected to Mayan.

/usr/local/python shell

execute the following:

from documents.models import Document
from converter.models import Transformation

[Transformation.objects.get_for_model(document).delete() for document in 
Document.objects.all()]

I'll push the option of adding an entry to the tools menu to clear all 
transformation in the queue for next version.

On Thursday, July 26, 2018 at 11:10:23 AM UTC-4, RBS wrote:
>
> BTW, We are using version 2.7.3 running under docker
>
>
> On Thursday, July 26, 2018 at 10:03:17 AM UTC-5, RBS wrote:
>>
>> Just recently started using Mayan and we had a user upload around 1800 
>> documents.  Almost all of these documents had a transformation of 
>> {"degrees": 180} added and should not have.  How can I easily remove the 
>> transformations from all documents in the system?  Thanks!
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2625] Re: Deploying mayan edms on ubuntu16.04

[Roberto Rosario]

Indeed. The documentation will be updated to specify Ubuntu 18.04. The 
previous 16,04 LTS version works but the old location of the GPG binary 
must be specified via SIGNATURES_GPG_PATH variable. 

On Thursday, July 26, 2018 at 9:34:27 AM UTC-4, Adam Kaney wrote:
>
> I tried doing this and ran into a pile of issues. I found it was easier to 
> install Ubuntu 18.04 and install on that. It was a very seamless install 
> after the upgrade

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2624] Re: Filtering a document queryset on the ACL/role name

[Roberto Rosario]

Makes sense to filter documents. An ideal solution would be to correlation 
the OS username to a Mayan user to inherit the permission. Or in the mean 
time a filtering method via the mountindex command line to avoid needing to 
change the code. Your question brings an interesting proposition to the 
mountindex feature.

On Tuesday, July 31, 2018 at 8:52:01 AM UTC-4, LeVon Smoker wrote:
>
> I figured it out eventually. In the 
> mirroring/management/commands/mountindex.py, I added...
> acls = AccessControlList.objects.filter(role__label='My Role', 
> permissions__name='document_view')
> queryset = queryset.filter(acls__in=acls) 
>
>
>
> On Friday, July 27, 2018 at 10:12:21 AM UTC-4, LeVon Smoker wrote:
>>
>> How can I do this? I intend to make my own version of the mountindex 
>> command that would allow filtering documents based on a role. I assume it's 
>> like filtering on a Generic Relation, but I can't figure it out...
>>
>>
>> https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericRelation
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2623] Re: Customize the search form

[Roberto Rosario]

Autocomplete is possible but will require a new API to return the top 
result values so that a smart widget like Select2 could display them. 
Possible but requires code changes. 

What do you mean by "change the field labels"? Can you expand on this? This 
one might be simpler to implement.


On Tuesday, July 31, 2018 at 2:17:45 PM UTC-4, LeVon Smoker wrote:
>
> Is there a good way to do this to...
> - change the field labels
> - add a custom search widget (autocomplete)
>
> As always, I don't want to hack the original source code...
>
> Thanks.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2622] Re: Use document's metadata for filename (Quick Labels)

[Roberto Rosario]

We've been testing ideas for something like this. Unfortunately it would 
only work once the document is uploaded and available in the system. This 
is because during the upload wizard the document still doesn't exist and 
cannot be referenced by a template variable like {{ document...}}. 
Templated quick labels would only work after the document is uploaded by 
going to the document properties edit view. 

A related feature we are working on right now is allowing the renaming of a 
document via workflow actions. This way a document is uploaded and when the 
workflow triggers a state (initial or otherwise) the rename action is 
executed. In this format a templated label field would have access to all 
of the document's properties including metadata values. This is in the 
works right now and very possible to be included in the next release 
(version 3.1).


On Wednesday, August 8, 2018 at 8:59:57 AM UTC-4, Martin Kinitzki wrote:
>
> Hey guys,
>
> is there any way to use a document's metadata (I added a metadata field 
> for suppliers) for renaming documents via quick label? I tried it with {{ 
> document.metadata_value_of.supplier }} with supplier being my metadata 
> field. Unfortunately it takes {{ document.metadata_value_of.supplier }} as 
> a String. 
> The reason is that I would like to have the filenames in that way: 
> *-MM-DD 
> Invoice Supplier*
>
> Thanks in advance.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2619] Getting Email to Work

[Roberto Rosario]

Some things to check:

- Check the spam folder of the receiving email.
- Look at the console for additional debug information.
- If using two step authentication, create what Google calls an user app
with separate credentials from the main account.
- Make sure the task scheduler is working. Emails are processed in the
background and not when the send button is pressed.

On Fri, Aug 3, 2018, 3:51 PM Ray Hendricks  wrote:

> Does anyone have email working to send email through either Gmail or
> office365?
>
> I'm using mayan 3.0 and can't get any email to send and there is nothing
> in the error log.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Mayan EDMS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mayan-edms+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2618] New Wiki available

[Roberto Rosario]

After weeks of trying out several Wiki tools and providers we've finally 
settled on a solution. The Wiki is self hosted and open to editing. This 
means that there is no need to create an account to create content. The aim 
is to lower the requirements for participation.

The address of the wiki is https://wiki.mayan-edms.com

Will the Wiki become an editable version of the documentation or a new 
knowledge repository to compliment it? We don't know, we'll the Wiki evolve 
as organically as possible to serve the community as best as possible. 
Thank you. 

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2616] Database conversion from SQLite to PostgreSQL (or MySQL)

[Roberto Rosario]

At the moment Django (the web framework used by Mayan) doesn't provide an 
official method to migrate from database engine to another.

It should not be up to an application software to perform platform, 
framework or OS work.

However, since many Mayan users are not familiar with Django or database 
engines (and they shouldn't need to) we've started a branch to add support 
for conversion of the database backend by Mayan itself. The branch is 
available 
here: https://gitlab.com/mayan-edms/mayan-edms/tree/feature/db_migration

We are focusing on making the database conversion as simple as possible. 
For this we are creating a command line program that will export the data 
from SQLite and import it to a new initialized PostgreSQL or MySQL 
database. We are calling this command 'convertdb'. Since the SQL file from 
one database vendor is not compatible with the SQL format of another vendor 
the data is exported using JSON (a database independent format) format 
using Django's DUMPDATA and LOADDATA commands. DUMPDATA and LOADDATA were 
not made for database migrations, they were designed to create FIXTURE 
files. FIXTURES are files that initialized a database with some data for 
use in test suits. Our tests indicate that these commands are suitable for 
export and import of data.

Since not all databases increment primary keys in the same way, the 
ordering of records can be lost during the conversion and the import will 
fail. To avoid this we are adding support to reference database objects 
using natural keys. These allow referencing a database object by a field or 
a collection of fields that are naturally unique, instead of using an 
autogenerate primary key number. These natural keys are used only during 
the database conversion and not for normal operation. Natural keys ensure 
that all database object relationships remain intact after the conversion.

Creating natural keys is a slow process of analysis and introspection of 
all the models defined in the Mayan apps. It is also a process that 
involves a lot of testing and simulation. We've given this feature top 
priority. Once this support is stable it will be included in the next 
planned release, version 3.1 so that user can start enjoying the benefits 
of the 3.x series without worrying about database migrations. Thank you.


-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2463] Re: Error with OCR in Spanish - Mayan 2.7

[Roberto Rosario]

Thanks for update Pablo, this will help fix the issue faster.

On Fri, May 11, 2018, 4:18 PM Pablo Castro 
wrote:

> UPDATE
>
> I was able to get the spanish OCR working by simply deleting the
> mayan-edms docker container and running it again, this successfully
> installed tesseract-ocr-spa.deb
>
>
>
> On Friday, 11 May 2018 12:37:39 UTC-5, Pablo Castro wrote:
>>
>> Hello,
>>
>> I installed Mayan with the following guide:
>> https://www.mayan-edms.com/post/deploy-mayan-docker-mysql/
>>
>> Which means I have 2 docker containers with Mayan-EDMS and MySQL running
>> in an Ubuntu box.
>>
>> I tried the OCR function but was getting the following error in the OCR
>> errors log:
>>
>> (1366, "Incorrect string value: '\\xEF\\xAC\\x81\\x0A21...' for column
>> 'content' at row 1")
>>
>> Tried with a different document and got a similar error:
>>
>> (1366, "Incorrect string value: '\\xEF\\xAC\\x81eio...' for column
>> 'content' at row 1")
>>
>> I assumed it was because the documents were being uploaded with "English"
>> as the document language, so I changed the default document language as
>> follows:
>>
>>
>> I modified the local.py file under
>> var/lib/docker/volumes/mayan_data/_data/settings and added the following
>> lines:
>>
>> DOCUMENTS_LANGUAGE_CHOICES = (('deu', 'Deutsch'),('eng', 'English'), (
>> 'spa', 'Spanish'))
>> DOCUMENTS_LANGUAGE = 'spa'
>>
>> This worked fine and now the default language when adding a new document
>> is Spanish and the list contains just spanish, english and german.
>>
>> Afterwards, I modified the envfile to install the spansh tesseract package
>>
>> # MySQL container
>> MYSQL_ROOT_PASSWORD=
>> MYSQL_PASSWORD=*
>> MYSQL_DATABASE=mayan_db
>> MYSQL_USER=mayan_user
>>
>> # Mayan container
>> MAYAN_DATABASE_DRIVER=django.db.backends.mysql
>> MAYAN_DATABASE_NAME=mayan_db
>> MAYAN_DATABASE_USER=mayan_user
>> MAYAN_DATABASE_PASSWORD=
>> MAYAN_DATABASE_HOST=mayan-mysql
>> MAYAN_DATABASE_PORT=3306
>> MAYAN_APT_INSTALLS=libsasl2-dev python-dev libldap2-dev libssl-dev
>> *tesseract-ocr-spa*
>> MAYAN_PIP_INSTALLS=python-ldap==2.4.41 django-auth-ldap==1.2.14
>>
>> I assumed this should be enough for OCR to be working in spanish, so I
>> restarted the docker container and uploaded a document for OCR
>>
>> OCR is still not working, and there's no error log under the OCR errors
>> tool.
>>
>> I checked the docker logs for the mayan-edms container and found this:
>>
>> Error opening data file /usr/share/tesseract-ocr/tessdata/spa.traineddata
>> Please make sure the TESSDATA_PREFIX environment variable is set to the
>> parent directory of your "tessdata" directory.
>> Failed loading language 'spa'
>> Tesseract couldn't load any languages!
>> [2018-05-11 16:55:37,489: ERROR/MainProcess] Task
>> ocr.tasks.task_do_ocr[fb11d940-faaa-4d51-8eb1-a20227ced574] raised
>> unexpected: WorkerLostError('Worker exited prematurely: signal 11
>> (SIGSEGV).',)
>> Traceback (most recent call last):
>>   File "/usr/local/lib/python2.7/dist-packages/billiard/pool.py", line
>> 1175, in mark_as_worker_lost
>> human_status(exitcode)),
>> WorkerLostError: Worker exited prematurely: signal 11 (SIGSEGV).
>>
>>
>> Has anyone experienced something similar? I am still searching for ways
>> to modify the TESSDATA_PREFIX environment variable but my experience with
>> docker is limited.
>>
>> Any help is appreciated.
>>
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Mayan EDMS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mayan-edms+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2462] Re: Version 3.0 beta 2 out

[Roberto Rosario]

The Python package will also be released too. The update is to allow us to 
release Docker images faster too but those won't substitute the Python 
package. 

Thank you for the feedback and supporting the project.

On Friday, May 11, 2018 at 11:05:51 AM UTC-4, Victor Zele wrote:
>
> Will there still be a standard PIP install method for these packages or 
> should I figure out how to change my installation from PIP to docker?
>
> thanks for the hard work!
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2461] Re: Version 3.0 beta 2 out

[Roberto Rosario]

It seems the javascript download step is not executing. Will get on it. 
Thanks for testing!

On Friday, May 11, 2018 at 4:36:06 AM UTC-4, Olimpiu Rob wrote:
>
> The /static/appearance/node_modules/ is missing, the rest seem to be 
> loading
>
> On Friday, 11 May 2018 11:21:47 UTC+3, Olimpiu Rob wrote:
>>
>> I'm missing the static resources when running the latest docker image.
>>
>> On Friday, 11 May 2018 06:54:35 UTC+3, Roberto Rosario wrote:
>>>
>>> New beta version out. With this beta the hope is to get feedback about 
>>> the new way Mayan EDMS installs and the new way the Docker image is produce 
>>> and hosted.
>>>
>>> Previously, a blank "media" folder was committed to the repository. This 
>>> folder is used to store document files, image caches and document 
>>> signatures. User settings were managed using a local.py module in the 
>>> "settings" folder.
>>> This created a difficult situation where there had to be a writable 
>>> directory committed to the repository. This also meant having to do use 
>>> some tricks to allow the initial setup to complete even thought there was 
>>> no user setting file and no secret key available, something Django doesn't 
>>> allow. The way Mayan solved this was by reverting to a default setting file 
>>> when there was no user settings file. With this new beta, now even the user 
>>> setting will be stored in the "media" folder inside an additional 
>>> "settings" folder. This way all installation artifacts are now contained in 
>>> a separate directory that is not part of the code repository. This also 
>>> allows recreating this entire media folder at runtime, thus removing the 
>>> requirement of the Docker image to only used named volumes. 
>>>
>>> Another change for this beta is that the Docker repository is now merged 
>>> back into the main repository. Until now only stable release were available 
>>> as Docker images. This is because these releases were done manually. After 
>>> a stable Mayan Python package was released, the Docker repository was 
>>> updated and pushed to BitBucket which in turn triggered the automated 
>>> creation of a new image in the Docker registry. This meant that when errors 
>>> with the Docker image were found we sometimes had to go back to the Mayan 
>>> Python code repository, make changes, make another release, and return to 
>>> the continue work on the Docker repository. Now that the Docker image 
>>> creation is part of the main repository this happens in the same debugging 
>>> process. 
>>>
>>> Another change is that we are now using GitLab's Docker registry to 
>>> generate the Docker images. The images are also automatically generated 
>>> when the test suit completes without error. This means that for each 
>>> successful commit of new code a new daily docker images will be available. 
>>> This allows for continuous deliver of Docker images. The images are tagged 
>>> with the branch that was used to generate them and can be found here: 
>>> https://gitlab.com/mayan-edms/mayan-edms/container_registry When you 
>>> checkout image "registry.gitlab.com/mayan-edms/mayan-edms:feature-docker" 
>>> you will be pulling the latest image built from code from the 
>>> "feature/docker" branch. The image "
>>> registry.gitlab.com/mayan-edms/mayan-edms:versions-next" will be from 
>>> code from the "versions/next" branch, the branch with the latest 
>>> development code that will become the next stable release. When a stable 
>>> release happens the images will be tagged with the version number and a 
>>> special tagged named "latest" will point to the latest release. This setup 
>>> allows the production of nightly as well as stable images using the same 
>>> setup. To try out the latest development image use:
>>>
>>> docker pull registry.gitlab.com/mayan-edms/mayan-edms:versions-next
>>>
>>> docker run -d --name mayan-edms-nightly --restart=always -p 8000:8000 -v 
>>> /docker-volumes/mayan-nightly:/var/lib/mayan 
>>> registry.gitlab.com/mayan-edms/mayan-edms:versions-next 
>>>
>>> Since the gunicorn app server is now used instead of NGINX the default 
>>> port has changed to 8000. This change is internal to the Docker container. 
>>> Docker port mapping can still be used to present port 8000 of the container 
>>> as port 80 of the machine by using -p 80:8000.  
>>>
>>> The documentation for the Docker image will be merged as a chapter of 
>>> the main documentation. 
>>>
>>>
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2454] Re: Domain isolation

[Roberto Rosario]

It was an issue on 2.7.3 since fixed. Just release 3.0 beta 2 containing 
the fix: https://groups.google.com/d/msg/mayan-edms/iuUOAhiP9ys/aWl6l2sNCQAJ

Nightly Docker images are also now available for easier testing.

On Monday, April 23, 2018 at 2:42:02 PM UTC-4, Victor Zele wrote:
>
> Must be a bug since moving to cabinets.  I believe I had restrictions on 
> folders in the past.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2453] Re: Cabinet Permissions

[Roberto Rosario]

It is solved in development. Just release 3.0 beta 2 for 
testing: https://groups.google.com/d/msg/mayan-edms/iuUOAhiP9ys/aWl6l2sNCQAJ

On Thursday, May 10, 2018 at 2:43:36 PM UTC-4, Hevon Gordon wrote:
>
> Was this issue ever resolved?
>
> On Saturday, July 1, 2017 at 7:00:07 AM UTC-5, cmdsou...@gmail.com wrote:
>>
>> Hi, 
>>
>> Have similar problems with permissions,
>>
>> have created cabinets for different groups of people with appropriate 
>> acls applied,
>> However am not being able to see the cabinets while trying to move the 
>> docs by a user to a specific cabinet, if i assign the permission to the 
>> role "Add documents to cabinets", then the user is able to add the document 
>> to his assigned cabinet,
>>
>> what is fail to understand is that he is able to add docs to cabinets to 
>> which he is not assigned permissions to, this is weird
>>
>> is there a way to do this i tried all sorts of combinations but with the 
>> "Add documents to cabinets" permission at the role level he is able to move 
>> the doc to any cabinet he wants to.
>>
>>
>>
>> On Wednesday, June 7, 2017 at 5:41:02 AM UTC+5:30, David Kornahrens wrote:
>>>
>>> I'm having a slight problem understanding the workflow in terms of 
>>> restricting data.
>>>
>>> So I have a user "Test" that I have assigned to "Group A".  
>>>
>>> "Group A" has been granted a role of "standard users" with permissions 
>>> to view cabinets (but only because I want them to see Cabinet "A" and see 
>>> the structure.  Then I selected to allow that role to "view documents".
>>>
>>> However, it appears they can now see each cabinet and all the documents 
>>> within.
>>>
>>> What am I missing here?  How can I get Cabinet A to only be viewable to 
>>> "Cabinet A".   Cabinet B to only be viewable by Cabinet B and so forth?
>>>
>>> Of course, Admin's will be able to view across cabinets.  If this is not 
>>> a possibility, this extremely limits our ability to utilize this platform.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2452] Version 3.0 beta 2 out

[Roberto Rosario]

New beta version out. With this beta the hope is to get feedback about the 
new way Mayan EDMS installs and the new way the Docker image is produce and 
hosted.

Previously, a blank "media" folder was committed to the repository. This 
folder is used to store document files, image caches and document 
signatures. User settings were managed using a local.py module in the 
"settings" folder.
This created a difficult situation where there had to be a writable 
directory committed to the repository. This also meant having to do use 
some tricks to allow the initial setup to complete even thought there was 
no user setting file and no secret key available, something Django doesn't 
allow. The way Mayan solved this was by reverting to a default setting file 
when there was no user settings file. With this new beta, now even the user 
setting will be stored in the "media" folder inside an additional 
"settings" folder. This way all installation artifacts are now contained in 
a separate directory that is not part of the code repository. This also 
allows recreating this entire media folder at runtime, thus removing the 
requirement of the Docker image to only used named volumes. 

Another change for this beta is that the Docker repository is now merged 
back into the main repository. Until now only stable release were available 
as Docker images. This is because these releases were done manually. After 
a stable Mayan Python package was released, the Docker repository was 
updated and pushed to BitBucket which in turn triggered the automated 
creation of a new image in the Docker registry. This meant that when errors 
with the Docker image were found we sometimes had to go back to the Mayan 
Python code repository, make changes, make another release, and return to 
the continue work on the Docker repository. Now that the Docker image 
creation is part of the main repository this happens in the same debugging 
process. 

Another change is that we are now using GitLab's Docker registry to 
generate the Docker images. The images are also automatically generated 
when the test suit completes without error. This means that for each 
successful commit of new code a new daily docker images will be available. 
This allows for continuous deliver of Docker images. The images are tagged 
with the branch that was used to generate them and can be found here: 
https://gitlab.com/mayan-edms/mayan-edms/container_registry When you 
checkout image "registry.gitlab.com/mayan-edms/mayan-edms:feature-docker" 
you will be pulling the latest image built from code from the 
"feature/docker" branch. The image 
"registry.gitlab.com/mayan-edms/mayan-edms:versions-next" will be from code 
from the "versions/next" branch, the branch with the latest development 
code that will become the next stable release. When a stable release 
happens the images will be tagged with the version number and a special 
tagged named "latest" will point to the latest release. This setup allows 
the production of nightly as well as stable images using the same setup. To 
try out the latest development image use:

docker pull registry.gitlab.com/mayan-edms/mayan-edms:versions-next

docker run -d --name mayan-edms-nightly --restart=always -p 8000:8000 -v 
/docker-volumes/mayan-nightly:/var/lib/mayan 
registry.gitlab.com/mayan-edms/mayan-edms:versions-next 

Since the gunicorn app server is now used instead of NGINX the default port 
has changed to 8000. This change is internal to the Docker container. 
Docker port mapping can still be used to present port 8000 of the container 
as port 80 of the machine by using -p 80:8000.  

The documentation for the Docker image will be merged as a chapter of the 
main documentation. 



-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2449] Medium article about my solar powered Mayan microserver

[Roberto Rosario]

https://medium.com/@siloraptor/solar-powered-microservers-for-a-post-hurricane-maria-puerto-rico-ca83027d20ac

Hope it can be useful for anyone else.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2446] Re: Mayan EDMS version 3.0 beta 1 available for testing

[Roberto Rosario]

The generated development docker images are located here:
https://gitlab.com/mayan-edms/mayan-edms/container_registry
 (Development image, not tested, use with caution and never in production).

This is the latest continuous integration setup:
https://gitlab.com/mayan-edms/mayan-edms/blob/feature/docker/.gitlab-ci.yml

First the code is tested using a python deployment against MySQL, SQLite
and Postgres. If all test pass, the docker image is built and pushed to
GitLab's docker registry. These images are tagged automatically based on
the git branch name used to generate them.

The last step to add is to run the tests one last time but inside the
generated docker image. If any one has experience with GitLab's CI and CD
setups and could lend a hand we can complete this sooner and have these
images ready for general download.

On Mon, May 7, 2018, 4:17 AM Roberto Rosario <
roberto.rosario.gonza...@gmail.com> wrote:

> We've been improving the continious integration setup to generate
> development Docker images alongside the automatic python testing. We just
> need to add code to test these automatic Docker images too and they will be
> ready for download.
>
> On Sun, May 6, 2018, 5:40 PM Raul  wrote:
>
>> I would also be interested in a docker image for testing.
>> Will there be one?
>>
>> Am Samstag, 28. April 2018 00:51:58 UTC+2 schrieb David Kornahrens:
>>>
>>> Hello Roberto --
>>> Glad to see you back around.
>>>
>>> I'm interested in testing out too.  Could you create a Docker upgrade
>>> for this, as that is how I'm deployed with Django Storages for offloading
>>> files.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>
>>> On Tuesday, April 10, 2018 at 9:21:03 PM UTC-4, Roberto Rosario wrote:
>>>>
>>>> This version is meant for users experienced with Mayan EDMS. Please do
>>>> not in production. The purpose of this release is get feedback on all the
>>>> changes and testing and bugs reporting. If want to test against real data,
>>>> please make a separate copy of your documents and database first and use
>>>> this copy for testing.
>>>>
>>>> Almost all the changes of Mayan EDMS NG 2.8 and Mayan EDMS NG 3.0 have
>>>> been merged.
>>>>
>>>> The release notes summary is as follows:
>>>>
>>>>
>>>>- Turning Mayan EDMS into a single page app. Views are rendered
>>>>using partial templates. On the first render a root template containing 
>>>> the
>>>>menus, JavaScript and stying is sent to the browser. On subsequent usage
>>>>only the area below the menu is refreshed. This results is a big speed
>>>>boost and much less bandwidth consumption.
>>>>- Project moved to Django 1.11.
>>>>- Event notification. It is possible to subscribe to an event type
>>>>for the entire system or to the event type of a specific document. If 
>>>> any
>>>>of these subscribed events occur an entry will be added to the 
>>>> notification
>>>>menu entry. The default for this menu entry is to display a bell icon 
>>>> and a
>>>>badge with the number of unread notifications.
>>>>- All the Python dependencies have been upgraded to their latest
>>>>version.
>>>>- The logic for searching documents is now different. Before, all
>>>>the documents that matched at least one of the search terms were 
>>>> returned.
>>>>Now only the documents that match all the terms are returned. This is in
>>>>essence an "AND" style logic. To allow the previous behavior, the "OR"
>>>>search syntax was added. The syntax must be added in uppercase and 
>>>> between
>>>>the optional terms.
>>>>- Normally the resolution for the display modes of documents was
>>>>specified as a string containing the width and height concatenated with 
>>>> the
>>>>character 'x'. The display resolution settings have been separated into
>>>>distinctive width and height settings. Instead of 
>>>> DOCUMENTS_THUMBNAIL_SIZE,
>>>>the settings are now DOCUMENTS_THUMBNAIL_WIDTH and
>>>>DOCUMENTS_THUMBNAIL_HEIGHT. The same applies to the preview, display and
>>>>print resolutions.
>>>>- The upload wizard now features dynamic steps. The steps are
>>>>defined by a new class called Wizard

Re: [Mayan EDMS: 2445] Re: Mayan EDMS version 3.0 beta 1 available for testing

[Roberto Rosario]

We've been improving the continious integration setup to generate
development Docker images alongside the automatic python testing. We just
need to add code to test these automatic Docker images too and they will be
ready for download.

On Sun, May 6, 2018, 5:40 PM Raul  wrote:

> I would also be interested in a docker image for testing.
> Will there be one?
>
> Am Samstag, 28. April 2018 00:51:58 UTC+2 schrieb David Kornahrens:
>>
>> Hello Roberto --
>> Glad to see you back around.
>>
>> I'm interested in testing out too.  Could you create a Docker upgrade for
>> this, as that is how I'm deployed with Django Storages for offloading files.
>>
>> Thanks,
>> David
>>
>>
>>
>> On Tuesday, April 10, 2018 at 9:21:03 PM UTC-4, Roberto Rosario wrote:
>>>
>>> This version is meant for users experienced with Mayan EDMS. Please do
>>> not in production. The purpose of this release is get feedback on all the
>>> changes and testing and bugs reporting. If want to test against real data,
>>> please make a separate copy of your documents and database first and use
>>> this copy for testing.
>>>
>>> Almost all the changes of Mayan EDMS NG 2.8 and Mayan EDMS NG 3.0 have
>>> been merged.
>>>
>>> The release notes summary is as follows:
>>>
>>>
>>>- Turning Mayan EDMS into a single page app. Views are rendered
>>>using partial templates. On the first render a root template containing 
>>> the
>>>menus, JavaScript and stying is sent to the browser. On subsequent usage
>>>only the area below the menu is refreshed. This results is a big speed
>>>boost and much less bandwidth consumption.
>>>- Project moved to Django 1.11.
>>>- Event notification. It is possible to subscribe to an event type
>>>for the entire system or to the event type of a specific document. If any
>>>of these subscribed events occur an entry will be added to the 
>>> notification
>>>menu entry. The default for this menu entry is to display a bell icon 
>>> and a
>>>badge with the number of unread notifications.
>>>- All the Python dependencies have been upgraded to their latest
>>>version.
>>>- The logic for searching documents is now different. Before, all
>>>the documents that matched at least one of the search terms were 
>>> returned.
>>>Now only the documents that match all the terms are returned. This is in
>>>essence an "AND" style logic. To allow the previous behavior, the "OR"
>>>search syntax was added. The syntax must be added in uppercase and 
>>> between
>>>the optional terms.
>>>- Normally the resolution for the display modes of documents was
>>>specified as a string containing the width and height concatenated with 
>>> the
>>>character 'x'. The display resolution settings have been separated into
>>>distinctive width and height settings. Instead of 
>>> DOCUMENTS_THUMBNAIL_SIZE,
>>>the settings are now DOCUMENTS_THUMBNAIL_WIDTH and
>>>DOCUMENTS_THUMBNAIL_HEIGHT. The same applies to the preview, display and
>>>print resolutions.
>>>- The upload wizard now features dynamic steps. The steps are
>>>defined by a new class called WizardStep. This allows integrators to
>>>customize the upload wizard to add their own steps without having to 
>>> modify
>>>the core code. This change also add the capability of disabling existing
>>>wizard steps form third party apps without having to make core code
>>>modifications.
>>>- A new default step was added to the upload wizard to specify the
>>>cabinets of new documents.
>>>- The code that detect the automatic orientation of PDF has been
>>>disabled by default. It can be enabled via the
>>>DOCUMENTS_FIX_ORIENTATION=True setting.
>>>- A new proposal system has been added via the Mayan EDMS Request
>>>for Comment (or MERC for short) documents. The first two MERCs have been
>>>approved. MERC-1 which documents the process itself and MERC-2 which
>>>documents how API tests are to be written. Other MERCs are in review
>>>process.
>>>- If the duplicates of a document were deleted the original document
>>>would still show up in the duplicated document list with a duplicate 
>>> count
>>>of 0. This has been 

[Mayan EDMS: 2428] Mayan EDMS version 3.0 beta 1 available for testing

[Roberto Rosario]

This version is meant for users experienced with Mayan EDMS. Please do not 
in production. The purpose of this release is get feedback on all the 
changes and testing and bugs reporting. If want to test against real data, 
please make a separate copy of your documents and database first and use 
this copy for testing.

Almost all the changes of Mayan EDMS NG 2.8 and Mayan EDMS NG 3.0 have been 
merged.

The release notes summary is as follows:


   - Turning Mayan EDMS into a single page app. Views are rendered using 
   partial templates. On the first render a root template containing the 
   menus, JavaScript and stying is sent to the browser. On subsequent usage 
   only the area below the menu is refreshed. This results is a big speed 
   boost and much less bandwidth consumption.
   - Project moved to Django 1.11.
   - Event notification. It is possible to subscribe to an event type for 
   the entire system or to the event type of a specific document. If any of 
   these subscribed events occur an entry will be added to the notification 
   menu entry. The default for this menu entry is to display a bell icon and a 
   badge with the number of unread notifications.
   - All the Python dependencies have been upgraded to their latest version.
   - The logic for searching documents is now different. Before, all the 
   documents that matched at least one of the search terms were returned. Now 
   only the documents that match all the terms are returned. This is in 
   essence an "AND" style logic. To allow the previous behavior, the "OR" 
   search syntax was added. The syntax must be added in uppercase and between 
   the optional terms.
   - Normally the resolution for the display modes of documents was 
   specified as a string containing the width and height concatenated with the 
   character 'x'. The display resolution settings have been separated into 
   distinctive width and height settings. Instead of DOCUMENTS_THUMBNAIL_SIZE, 
   the settings are now DOCUMENTS_THUMBNAIL_WIDTH and 
   DOCUMENTS_THUMBNAIL_HEIGHT. The same applies to the preview, display and 
   print resolutions.
   - The upload wizard now features dynamic steps. The steps are defined by 
   a new class called WizardStep. This allows integrators to customize the 
   upload wizard to add their own steps without having to modify the core 
   code. This change also add the capability of disabling existing wizard 
   steps form third party apps without having to make core code modifications.
   - A new default step was added to the upload wizard to specify the 
   cabinets of new documents.
   - The code that detect the automatic orientation of PDF has been 
   disabled by default. It can be enabled via the 
   DOCUMENTS_FIX_ORIENTATION=True setting.
   - A new proposal system has been added via the Mayan EDMS Request for 
   Comment (or MERC for short) documents. The first two MERCs have been 
   approved. MERC-1 which documents the process itself and MERC-2 which 
   documents how API tests are to be written. Other MERCs are in review 
   process.
   - If the duplicates of a document were deleted the original document 
   would still show up in the duplicated document list with a duplicate count 
   of 0. This has been fixed.
   - Support was added to pass arguments to the storage drivers. This 
   removes the need to subclass a storage driver to change its behavior. This 
   also means that passing global variables via the  local.py file to use S3 
   style object storages is no longer required. These storage drivers can be 
   configure by passing their arguments in the new 
   DOCUMENTS_STORAGE_BACKEND_ARGUMENTS as a YAML string.
   - If is possible to list only the system events executed by one user. 
   This can be accomplished via the user list view in the setup menu. Or by 
   clicking on the user name of the event list view.
   - The checkbox behavior in all the views that display a list items has 
   been improved. A "check all" checkbox was added that will auto select all 
   items. The submit button from dropdown list of actions was removed. Instead 
   the action of selecting an item from the action dropdown will trigger the 
   action. The checkbox also allow block selection. Clicking on the checkbox 
   of the first item, later on the checkbox of the fifth item while holding 
   down the shift key will cause the checkboxes of items 1 to 5 to be 
   selected. The same applies to deselection.
   - A JavaScript library manager was added. This means that third party 
   JavaScript libraries are now not included with the distribution of Mayan 
   EDMS. These are downloaded when the new management command 
   installjavascript is executed. The installation of JavaScript libraries is 
   also performed during upgrades and initial installations.
   - Removing a workflow type from a document type will now also remove all 
   running copies of the remove workflow type from the documents of said 
   document type.
   - To prot

Re: [Mayan EDMS: 2425] Email template customizing

[Roberto Rosario]

Thanks!

That is a good idea. Please open an issue to help track it
https://gitlab.com/mayan-edms/mayan-edms/issues

On Friday, April 6, 2018 at 12:18:00 PM UTC-4, Victor Zele wrote:
>
> Thanks Roberto, great to have you back online.
>
> It works as expected!
>
> Now any way to set the message header type variable for Django, 
> html_message, so that the message body content is flagged as fancy HTML 
> code and not just plain text?
>
> Victor 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2424] Re: PDF rotate option for documents

[Roberto Rosario]

The rotation issue since the last versions is actually caused by code that 
was added to try to detect PDF orientation in some edge cases. Ssince there 
are many unofficial and undocumented ways to rotate a PDF, it is not 
working 100% of the time. That is why it is now disabled by default and 
controlled via the DOCUMENTS_FIX_ORIENTATION setting. 
https://gitlab.com/mayan-edms/mayan-edms/commit/b06918c333fb582d749ffd255019223fb08ecb92

Better to have good orientation detection for good PDF than try to detect 
orientation in bad PDF and screw up detection for all PDFs.

On Friday, April 6, 2018 at 12:45:59 PM UTC-4, Victor Zele wrote:
>
> Hi Roberto,
>
> As a new feature request, would be nice to use pdftk opensource tool with 
> command line option to rotate any PDFs that come in sideways.
> Right now I have to download the document version, run pdftk command like 
> below and upload the output PDF as a new version for parsing and OCR again.
>
> # pdftk DOC-20180326-1045-0.pdf cat 1-endwest output output-rotated.pdf
>
> Seems to keep resolution, etc. on the PDF and you can specify west 
> rotation for counter-clockwise or east for clockwise rotation, 1-end means 
> all pages which is usually the case.
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2418] Re: Mayan EDMS NG merge progress

[Roberto Rosario]

Hi Costi,

Yes, the migration fix is included. On top of the NG 2.8 and 3.0 changes 
there is:

- PDF orientation detection of by default but can be turned on by using a 
new setting.
- MERC-1 is approved and API test writing practices approved as MERC-2.
- Fix for document with 0 duplicates.
- Storage refactor. Ability to pass arguments to the storage driver was 
added. Makes using other storage drivers (Amazon, S3, encryption, 
compression, concatenated: compression+encryption+S3) much easier. Code 
donated by Paperattor team.
- Smart checkbox selector. Click on item 1 of a list, do a click+shift on 
item 10 and all items in between get selected.
- JavaScript dependency manager. JavaScript libraries are downloaded during 
installation. Make distributable size of Mayan smaller among other 
advantages.
- ACL support for roles, user and group. User other than administrators can 
now manage groups, roles and users.
- Visual improvements in statistics charts.
- Many other smaller fixes everywhere.

Yes, the Docker image will be updated after the release into the Python 
index server. Improvements from the Mayan EDMS NG docker images will also 
be incorporated.

On Thursday, April 5, 2018 at 4:36:16 AM UTC-4, Costi Budai wrote:
>
> Hi Roberto, these are the best news of the day!
> EDMS NG has now version 3.0.2(also docker image), they included a fix 
> regarding some migration errors, see topic Mayan EDMS NG 3.0 upgrade error 
> . Will 
> you include also this?
> When you release Mayan EDMS v3 we'll have also the docker image upgraded?
> Thanks.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2416] Mayan EDMS NG merge progress

[Roberto Rosario]

I've started merging the changes from Mayan EDMS NG. After getting all code 
revisions for version 2.8 I looked at the changes in version 3.0 and there 
we some good bug fixes and should be included. After adding the 3.0 bug 
fixes there was not real reason not to continue the merge of the remaining 
Mayan EDMS NG version 3.0 features.

As of today practically all Mayan EDMS NG changes and additions have been 
included into what will be the next Mayan EDMS.

The next release version of Mayan EDMS will be version 3.0. The version 
number will go from 2.7.3 to 3.0 skipping 2.8 and 2.9. The reasons for this 
jump in versions are:

- All changes from Mayan EDMS NG 2.8 and 3.0 were merged. Makes better 
sense to keep version numbers in sync with the most prominent fork.
- The authors of Mayan EDMS NG have no desire to maintain a free open 
source fork over the long run. And explained their work was meant to be 
temporary help to keep the project's momentum during my absence.
- API incompatible changes. The URLs for the API changed. This alone 
prompts a major number increment according to the semantic versioning best 
practices. The inclusion of a new Django version (1.11). Aside from this 
everything else is perfectly compatible. Database migrations are provided 
to allow upgrade of existing installation like any other previous release.
- My way of saying thank you for sticking around and supporting the 
project. It has been several months since the last release (2.7.3) so what 
better surprise than to launch a big release with lot of new features.

These are the only release blockers: 
- Update Chart.js
- Update toastr.js
- Add support for downloading the event log
- Check and fix high priority issues in GitLab
- Check and tix milestone 3 issues in GitLab
- Add Flake8 step to release checklist.
- Unify use os.unlink
- Audit the os.unlink uses in the code. Check that they are local and do 
not require Django storage.

After the release blockers there are some issues I would like to close if 
they don't prove too difficult and don't delay thinks too much.

- More compression types support (tar). Finish Git feature branch.
- Image overlay or watermark for when there is no print permission 
assigned. HIPAA requirement.
- Skip bad document signatures during perform upgrade
- Move the MetadataLookupIntegrationTestCase from user_management to 
metadata.
- Reduce document paging size. Or add separate paging sizes.
- New installer to create separate sites (no settings.local.py buried) 
(https://gitlab.com/mayan-edms/mayan-edms/issues/134). Might help with the 
Docker named volume issue.

Work is being done in the versions/next 
branch: https://gitlab.com/mayan-edms/mayan-edms/tree/versions/next

Release notes for what has been done already: 
https://gitlab.com/mayan-edms/mayan-edms/blob/versions/next/docs/releases/3.0.rst

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2401] Situation update

[Roberto Rosario]

Big thank you to everybody that has reached out, sent first necessity 
items, and donated. You have made a situation without precedent much more 
bearable. 

This is the situation at the moment (without going into politics or 
corruption, that has gone to a whole new level of insanity).

Utilities are mostly working. There are still a several outages per week 
but in comparison with having no power, it is a much better situation. Now 
we can purchase groceries knowing the chances of it spoiling are much 
lower. 

Internet and cell phone service are still spotty. We get 1Mbit of download 
speed. Using heavy ad filtering and compression browsing experience is 
tolerable but trying to watch streaming content is painful. The same goes 
for VOIP and video calls. Remote work takes patience.

Driving around is still an adventure. A lot of traffic lights are still 
out. Intersections are like a gauntlet. Patience in the streets is low and 
people are very prone to road rage. Traffic jams last hours. In those 
situations phone navigation is useless as there are still many connectivity 
dark zones.

Like most people in the island, my income sources have been gravely 
affected. Spending now the same amount of time I used to spend on Mayan and 
my other free projects is a luxury I can't afford. I hope to be able to 
take some time soon to revise all the work done by the Mayan EDMS NG team 
and start merging. Since their fork has moved quite a bit ahead of Mayan 
EDMS, this revision and merge process will be mostly manual. To make the 
most of the time, I'll focus on bug fixes and outdated version updates 
(Django, packages, etc), before going into features. From what I've seen so 
far, they have done a very good job. Their job quality will make mine 
easier.

This has been the worst natural disaster in generations and one of the 
worse experiences I've had to go through. But we survived it and that's all 
that matters. We rebuilt our island. And we will rebuild this, our project.

Thank again to everybody.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2218] Regarding Mayan after hurricane Maria

[Roberto Rosario]

https://www.mayan-edms.com/post/hurricane-maria/

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2168] Roberto And the Hurricane

[Roberto Rosario]

Thank you everybody for the concerns and you wishes, they are very 
appreciated!

Hurricane Maria took down whatever hurricane Irma left standing. For a few 
days the entire island was without electricity, water, and communications.
All radio stations were offline too.

3 weeks later, I'm still without power (only 17% of residents have 
electricity http://status.pr/) but have setup a small
solar power system and my ISP is partially back online. Water service has 
been restored too but we are still drinking
bottled water as a precaution.

As the services and situation continue to improve I'll try to retake where 
things left off and be more present in the group.

Thank you everybody.

On Friday, October 6, 2017 at 10:38:28 AM UTC-4, Angel Rosario wrote:
>
> Thank you!! 
>
> I will. 
>
> Best regards, 
>
> -Original Message- 
> From: mayan-edms@googlegroups.com [mailto:mayan-edms@googlegroups.com] On 
> Behalf Of Mathias Behrle 
> Sent: Friday, October 6, 2017 3:41 AM 
> To: mayan-edms@googlegroups.com 
> Subject: Re: [Mayan EDMS: 2156] Roberto And the Hurricane 
>
> * Angel Rosario-Sierra \(rtm\): " RE: [Mayan EDMS: 2152] Roberto And the 
>   Hurricane" (Thu, 5 Oct 2017 12:51:22 -0400): 
>
> > Robert is OK.  Although, with poor communication  I have talked with 
> > him in several occasions. 
>
> Thanks a lot for the update and please pass best wishes to him (and of 
> course all Puerto Rican people)! 
>
> Mathias 
>
> -- 
>
> Mathias Behrle 
> PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 
> AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6 
>
> -- 
>
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Mayan EDMS" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to mayan-edms+unsubscr...@googlegroups.com. 
> For more options, visit https://groups.google.com/d/optout. 
>
>
> --- 
> This email has been checked for viruses by Avast antivirus software. 
> https://www.avast.com/antivirus 
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2120] Hurricane Maria

[Roberto Rosario]

Category 5 hurricane Maria is reaching Puerto Rico and set to make landfall 
in 3 hours. Due to the passing of hurricane Irma a few weeks ago, Puerto 
Rico's infrastructure is still not fully recovered and we have already lost 
electricity and broadband internet access. All of us here in Puerto Rico 
might be off-line for an unknown amount of time. In case you don't hear 
from me or other contributors from the island, keep the discussions and the 
GitLab issues going and we'll chime in from time to time as technology and 
climate allows. 

In preparation for the worst, I've setup a small Mayan microserver capable 
of running on USB power or a 12V car battery. I'm using an Odroid C2 inside 
an aluminum case. In case of emergency is just a matter of unplugging and 
dropping it into a bag. I'll be sharing photos and the setup I used to get 
decent performance out the SBC later on in hopes it can help anybody else 
in a similar situation.

Best regards and Godspeed to everybody else in the path of the hurricane.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2111] Re: Uploaded a few PDF within a .tar.gz archive (without paths), Mayan failed to process them

[Roberto Rosario]

At the moment only Zip files are supported. Here is the issue for adding 
Tar and Gzip support too: 
https://gitlab.com/mayan-edms/mayan-edms/issues/7. You can subscribe to the 
issue to be notified when it is closed. Work on this began some time ago in 
this branch: 
https://gitlab.com/mayan-edms/mayan-edms/tree/feature/improved_compressed_handler

The goal is to have this ready for the 3.0 release. 

On Friday, September 15, 2017 at 12:12:34 PM UTC-4, Hans Fritz wrote:
>
> I was wondering how the compressed files upload works.
>
> I added a few PDF files to a tar.gz archive which I uploaded through the 
> web importer. I checked the decompress files checkbox. But the worker 
> errors saying that Pillow couldn't find the number of pages in the document 
> (which is still gzipped once moved to Mayan's media storage dir, according 
> to the `file` command). It would seem that the tar.gz archive is never 
> unpacked, and Mayan tries to process it as if it were a regular document.
>
> What archive formats are supported? Should the archives be packed in a 
> specific way? The host running Mayan has all the necessary binaries for 
> handling gzipped tar files.
>
> Thanks,
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2110] Re: Active directory, LDAP integration

[Roberto Rosario]

We are working on 
it: https://gitlab.com/mayan-edms/mayan-edms-docker/issues/16#note_40193691

Subscribe to the issue to get the latest updates.

On Friday, September 15, 2017 at 4:05:00 PM UTC-4, Joe Nguyen wrote:
>
> Hi all, 
>
> I am using Mayan EDMS through Docker, how can and where I configure and 
> enable LDAP function on. 
>
> Thanks all, 
>
> Joe Nguyen 
>
>
>
> -- 
> Sent from: http://mayan-edms.1003.x6.nabble.com/ 
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2105] retaining file modification date of an uploaded file

[Roberto Rosario]

Hi,

Yes, I think creation and last modification date are only readable via
filesystem calls in Python. I'll take a look at all the internal to see if
this is true. If the dates are somehow available they can be added as two
extra fields in the document version model with no compatibility issues.

On Sep 13, 2017 12:17 PM, "Ben"  wrote:

Hi,

Is there any way to access or save the modification date of an uploaded
file? I need to upload thousands of old documents and I am using a watch
folder for it. The upload works fine but the document timestamp is the time
when the document was added to Mayan.
It would be nice to have the modification date of the file to filter
searches.
I cannot find anything in Django: The UploadedFile class has only a few
attributes  ( name, size, ... ) but no modification date.

Ben

-- 

---
You received this message because you are subscribed to the Google Groups
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2104] Searching for untagged / items not in any container

[Roberto Rosario]

Very ingenious solution!

On Tuesday, September 12, 2017 at 7:14:48 AM UTC-4, Glenn Corbett wrote:
>
> Hi Dave,
>
> Worked through that this evening, even better than what I was after!
>
> Thanks.
>
> Glenn 
>
> On Tuesday, 12 September 2017 13:29:46 UTC+10, David Kimmel wrote:
>>
>> Hi Glenn,
>>
>> I figured out a way to do this using Indexes.  Here are the rough steps:
>>
>> 1)  Create an index (System, Setup, Indexes).
>>
>> 2)  In the Tree Template, add a child node under the root node.  Make 
>> sure you select Link Documents.  Add the following expression:
>>
>> {% if document.tags.count == 0 and document.cabinets.count == 0 %}No 
>> Cabinets or Tags{% endif %}
>>
>> 2a)  At this point, you could add more child nodes under the root node to 
>> do other things.  For example, you could do something like this to find 
>> documents which have been tagged but not put in a cabinet:
>>
>> {% if document.tags.count > 0 and document.cabinets.count == 0 %}Tagged, 
>> but not in a Cabinet{% endif %}
>>
>> 2c)  You could even construct an if/else if structure to do it all in one 
>> node of the tree template.
>>
>> 3)  In the Document Types for the index, select the appropriate document 
>> types.
>>
>> 4)  Rebuild the index (System, Tools, Rebuild Indexes).
>>
>> 5)  Go to Indexes and make sure it’s doing what you expect.
>>
>> Once you’ve created the index it will keep itself up to date 
>> automatically as you add and update documents.  You can treat it as a saved 
>> search of sorts and just refer to it every time you want to look for 
>> documents that need to be processed.
>>
>> Hope that helps,
>> -- Dave Kimmel
>>davidj...@gmail.com
>>
>>
>>
>> On Sep 11, 2017, at 16:42, Glenn Corbett  wrote:
>>
>> All,
>>
>> Hopefully an easy one.
>>
>> Have just installed mayan EDMS, loving it so far.
>>
>> When searching for documents, is it possible to search for documents that 
>> are NOT tagged with anything, and also for documents that are NOT in any 
>> containers?
>>
>> As I am tagging and classifying documents, would like to be able to 
>> search for those documents I haven't processed yet, rather than have to 
>> continuously go through the full list of documents.
>>
>> Thanks.
>>
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mayan EDMS" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mayan-edms+...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2093] Re: Mayan EDMS version 2.7.2 released, Docker image 2.7.2-2 released.

[Roberto Rosario]

Change the line 50 from:

MAYAN_DATABASE_DRIVER: postgres

to:

MAYAN_DATABASE_DRIVER: django.db.backends.postgres

The driver name shorthand support was removed to keep driver names the same 
with Django.

On Thursday, September 7, 2017 at 7:32:07 PM UTC-4, Lin Pro wrote:
>
> Hi,
>
> En error gets displayed after:
>
> git clone ...
> docker-compose up -d
>
> docker logs mayan-edms-app:
>
> mayan.settings <7> [INFO] "() No local.py settings file. Using 
>> defaults."
>
> Traceback (most recent call last):
>
>   File "/usr/local/bin/mayan-edms.py", line 10, in 
>
> execute_from_command_line(sys.argv)
>
>   File 
>> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
>> line 367, in execute_from_command_line
>
> utility.execute()
>
>   File 
>> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
>> line 341, in execute
>
> django.setup()
>
>   File "/usr/local/lib/python2.7/dist-packages/django/__init__.py", line 
>> 27, in setup
>
> apps.populate(settings.INSTALLED_APPS)
>
>   File "/usr/local/lib/python2.7/dist-packages/django/apps/registry.py", 
>> line 108, in populate
>
> app_config.import_models(all_models)
>
>   File "/usr/local/lib/python2.7/dist-packages/django/apps/config.py", 
>> line 199, in import_models
>
> self.models_module = import_module(models_module_name)
>
>   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in 
>> import_module
>
> __import__(name)
>
>   File 
>> "/usr/local/lib/python2.7/dist-packages/django/contrib/auth/models.py", 
>> line 4, in 
>
> from django.contrib.auth.base_user import AbstractBaseUser, 
>> BaseUserManager
>
>   File 
>> "/usr/local/lib/python2.7/dist-packages/django/contrib/auth/base_user.py", 
>> line 52, in 
>
> class AbstractBaseUser(models.Model):
>
>   File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", 
>> line 119, in __new__
>
> new_class.add_to_class('_meta', Options(meta, app_label))
>
>   File "/usr/local/lib/python2.7/dist-packages/django/db/models/base.py", 
>> line 316, in add_to_class
>
> value.contribute_to_class(cls, name)
>
>   File 
>> "/usr/local/lib/python2.7/dist-packages/django/db/models/options.py", line 
>> 214, in contribute_to_class
>
> self.db_table = truncate_name(self.db_table, 
>> connection.ops.max_name_length())
>
>   File "/usr/local/lib/python2.7/dist-packages/django/db/__init__.py", 
>> line 33, in __getattr__
>
> return getattr(connections[DEFAULT_DB_ALIAS], item)
>
>   File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
>> 211, in __getitem__
>
> backend = load_backend(db['ENGINE'])
>
>   File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 
>> 134, in load_backend
>
> raise ImproperlyConfigured(error_msg)
>
> django.core.exceptions.ImproperlyConfigured: 'postgres' isn't an available 
>> database backend.
>
> Try using 'django.db.backends.XXX', where XXX is one of:
>
> 'mysql', 'oracle', 'postgresql', 'sqlite3'
>
> Error was: No module named postgres.base
>
>
>
> Anybody has a clue where to check?
>
> Thanks
>
> Lin
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2092] Re: empty continuation lines in EDMS Dockerfile, is it an issue?

[Roberto Rosario]

Seems to be a warning about something that will change in the future and 
will produce an error instead then. The empty lines in the Dockerfile are 
only there for visual clarity and can be removed in the future to silence 
the warning. Issue added to track this: 
https://gitlab.com/mayan-edms/mayan-edms-docker/issues/15

On Thursday, September 7, 2017 at 4:26:17 PM UTC-4, Lin Pro wrote:
>
> Hello,
> An error gets spit out while building EDMS from Dockerfile version 2.7.2-2
> But the image seems to have been built successfully. Should anything be 
> corrected in that file, though?
>
> Regards
> Lin
>
>
>  
>
>> Removing intermediate container 902f3815a574
>> [WARNING]: Empty continuation line found in:
>> RUN apt-get update && apt-get -o Dpkg::Options::="--force-confnew" 
>> dist-upgrade -y && apt-get install -y --no-install-recommends curl  
>>gcc gettext-base ghostscript gpgv
>>  graphviz libjpeg-dev libmagic1 libmysqlclient-dev  
>>libpng-dev libpq-dev libreoffice
>>  libtiff-dev locales nginx netcat-openbsd
>>  poppler-utils python-dev python-pip
>>  python-setuptools python-wheel redis-server
>>  supervisor tesseract-ocr && apt-get clean autoclean && apt-get 
>> autoremove --purge -y && rm -rf /var/lib/apt/lists/* && rm -f 
>> /var/cache/apt/archives/*.deb
>> [WARNING]: Empty continuation lines will become errors in a future 
>> release.
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2089] Re: possible to docker image include pip azure sdk 1.0 to allow django with azure

[Roberto Rosario]

I this a:

pip search azure-sdk

and it returns many results. What is the exact name of the package to 
install?

On Thursday, September 7, 2017 at 1:05:20 PM UTC-4, Tony Nys wrote:
>
> now i create my own docker file for only adding azure 1.0 sdk
> Is it possible to include it by default ?
>
> thx
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2089] Re: possible to docker image include pip azure sdk 1.0 to allow django with azure

[Roberto Rosario]

"I this a:" -> "I did a:"

On Thursday, September 7, 2017 at 11:30:18 PM UTC-4, Roberto Rosario wrote:
>
> I this a:
>
> pip search azure-sdk
>
> and it returns many results. What is the exact name of the package to 
> install?
>
> On Thursday, September 7, 2017 at 1:05:20 PM UTC-4, Tony Nys wrote:
>>
>> now i create my own docker file for only adding azure 1.0 sdk
>> Is it possible to include it by default ?
>>
>> thx
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2089] Re: mayan slow when external postgres database, configure django.db.backends

[Roberto Rosario]

To clarify: When you say "external Postgres (in Azure)" that means the 
Mayan container is in your local network and the PostgreSQL database is in 
the Azure cloud?

On Thursday, September 7, 2017 at 1:03:49 PM UTC-4, Tony Nys wrote:
>
> Mayan is extremely slow when targeting an external postgres.
> When I run the docker image locally and a local postgres , it is fast;
>
> but when I run towards an external Postgres (in Azure) it is extremely slow
> (5 seconds to show the recent document list page with only 2 docs)
>
> I try to debug the performance, so I'v put this logging inside
>
> /usr/share/mayan-edms/lib/python2.7/site-packages/mayan/settings/local.py
>
>
> However, it only logs the initial DDL of the "initialsetup" phase in mayan 
> db creation
>
> but not the queries and response times executing the SQL
>
>
> this is the log config:
>
>
> LOGGING = {
>
> 'version': 1,
>
> 'disable_existing_loggers': False,
>
> 'handlers': {
>
> 'file': {
>
> 'level': 'DEBUG',
>
> 'class': 'logging.FileHandler',
>
> 'filename': '/var/log/django.debug.log',
>
> },
>
> },
>
> 'loggers': {
>
> 'django.db.backends': {
>
> 'handlers': ['file'],
>
> 'level': 'DEBUG',
>
> 'propagate': True,
>
> },
>
> },
>
>
> }
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2088] Re: Cannot find out 'Default ACL'

[Roberto Rosario]

Hi,

There was once a feature called "Default ACLs", but it was removed 2 years 
ago (
https://gitlab.com/mayan-edms/mayan-edms/commit/5be41af1cfcdf65f7bee7cbbfbb9054c21c4e308)
 
when the permission system was refactored. Are you upgrading from version 
0.13?

On Thursday, September 7, 2017 at 3:54:58 AM UTC-4, Joe Nguyen wrote:
>
> Hi Roberto,
>
> I can not find out any item *Default ACL* in Setup menu (I have logged in 
> with user admin), version is 2.7.2-2
>
>
> 
>
> Thanks,
> Joe Nguyen
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2087] Re: Error trying to view Task Manager

[Roberto Rosario]

Yes indeed. There was an update in the base view classes to detect app 
views using the get_queryset method to produce a list of objects to 
display. The task manager app was not updated in relation to this change. 
Fixed committed: 
https://gitlab.com/mayan-edms/mayan-edms/commit/51026cc55ee596777a78c0b07748936ca967e69e.
 
Thanks for the report!

On Thursday, September 7, 2017 at 1:48:13 PM UTC-4, LeVon Smoker wrote:
>
> Getting this error - maybe a bug in task_manager/views.py?
>
>
> ImproperlyConfigured at /task_manager/queues/
>   
>
> QueueListView is overloading the get_queryset method. Subclasses should 
> implement the get_object_list method instead. 
>
>
>   
> Request Method: GET
> Request URL: http://documents.hrcsb.org/task_manager/queues/
> Django Version: 1.10.7
> Exception Type: ImproperlyConfigured
> Exception Value: 
>
> QueueListView is overloading the get_queryset method. Subclasses should 
> implement the get_object_list method instead. 
>
> Exception Location: /usr/share/mayan-edms/mayan/apps/common/generics.py 
> in __init__, line 491
> Python Executable: /usr/share/mayan-edms/bin/uwsgi
> Python Version: 2.7.9
> Python Path: 
>
> ['.',
>  '',
>  '/usr/share/mayan-edms/lib/python2.7',
>  '/usr/share/mayan-edms/lib/python2.7/plat-i386-linux-gnu',
>  '/usr/share/mayan-edms/lib/python2.7/lib-tk',
>  '/usr/share/mayan-edms/lib/python2.7/lib-old',
>  '/usr/share/mayan-edms/lib/python2.7/lib-dynload',
>  '/usr/lib/python2.7',
>  '/usr/lib/python2.7/plat-i386-linux-gnu',
>  '/usr/lib/python2.7/lib-tk',
>  '/usr/share/mayan-edms/local/lib/python2.7/site-packages',
>  '/usr/share/mayan-edms/lib/python2.7/site-packages',
>  u'/usr/share/mayan-edms/mayan/apps',
>  '/usr/share/mayan-edms']
>
> Server time: Thu, 7 Sep 2017 13:34:06 -0400
>
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2080] Mayan EDMS version 2.7.2 released, Docker image 2.7.2-2 released.

[Roberto Rosario]

Mayan EDMS version 2.7.2 is available.

Release notes:

Version 2.7.1


- Support unicode non-ascii metadata values when uploading a document
- Errors in local.py files are no longer silent and will stop initialization
- The file local.py is now generated to support unicode, string don't need 
to be prepended with an 'u'.

Version 2.7.2


- Fixes the new mailer creation view
- Event consolidation. 'document properties edited' events are not longer 
logged when uploading a new document.
- Cabinet list sorting.
- Add a visual cue for the document cabinet list. Document's cabinet list 
on the document item view cards are now shown in italics. 
- Easier testing of production deployments. The testing library mock is now 
installed by default.

Docker image changes.

- Staging and watch folder files with Unicode non-ASCII filename are now 
supported.

For the full release notes visit:

- 2.7.1: http://docs.mayan-edms.com/en/latest/releases/2.7.1.html
- 2.7.2: http://docs.mayan-edms.com/en/latest/releases/2.7.2.html

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2079] Re: mayan stateless cluster / docker swarm

[Roberto Rosario]

Once concern that comes to mind is making sure both instances have access 
to the same locks. For this you need to switch to a shared lock backend. 
Mayan includes one such backend using the database. In your local.py change 
(both instances) the config option LOCK_MANAGER_DEFAULT_BACKEND to 
'lock_manager.backends.model_lock.ModelLock'. This will cause the instances 
to write to a common database model to reserve and release resources so 
that both don't try to do OCR to the same document at the same time for 
example.

The other concern is data propagation delays. You can increase the default 
of two seconds to a higher number with COMMON_DB_SYNC_TASK_DELAY=3 or 
higher number. This will cause background tasks to wait the specified 
number of seconds before trying to access data that is still being 
propagated from one host to the other. Increase this number if you 
background tasks logs show that they are not finding a document that you 
know you uploaded.

The final concern is load balancing at the frontend to make sure requests 
are distributed in a fair manner between the two instances.

I look forward to hear from your experiences and any setup you used.

On Friday, August 11, 2017 at 2:39:22 AM UTC-4, Tony Nys wrote:
>
> I want to set up 2 mayan servers running the docker image
> Each server will be connected to the same database server (postgresql) and 
> the same external blob storage (eg. Azure)
>
> WIll there be any issue/concern setting up such a cluster / docker-swarm ?
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2078] Re: Mayan EDMS version 2.7 released

[Roberto Rosario]

Yes, since this is a minor version nothing else should change and just 
updating "mayan-edms==2.7" in the Dockerfile should be enough. Example: 
https://gitlab.com/mayan-edms/mayan-edms-docker/commit/35fb4f3da305753f98915f37d76bbcd814410f3c

You can run the full test suit by installing mock (needed by the tests) 
with:

pip install mock==2.0.0

and then with:

mayan-edms.py test --mayan-apps

This will validate if the updated version is working correctly in your 
setup.

The Python 3 support is still preliminary and not enabled in the Docker 
image. It is the start of the support for Python 3 for when Mayan moved to 
Django 2.0 which only supports Python 3. Mayan will continue to use Python 
2.7.x as the default for several months or even a year.

On Tuesday, September 5, 2017 at 7:58:08 PM UTC-4, Lin Pro wrote:
>
>
>>
> On Wednesday, August 30, 2017 at 3:38:37 PM UTC-5, Roberto Rosario wrote:
>>
>> Version 2.7 is available for download from Python Package Index (
>> https://pypi.python.org/pypi/mayan-edms/2.7). Docker image available 
>> soon.
>>
>>
> Thnak you for the new version. 
> I did the following to check it in docker:
>
> In Dockerfile:
> # Install Mayan EDMS, latest production release 
> RUN pip install mayan-edms==2.7
>
> In docker-compose2_7.yml:
> mayan-edms: 
>restart: always 
>container_name: mayan-edms-app 
>image: linforpros/mayanedms:2.7
>
> Following that:
> docker container rm mayanedms/mayan-edms-app
> docker build -t linforpros/mayanedms:2.7
> docker push linforpros/mayanedms:2.7
> docker-compose -f docker-compose2_7.yml up -d
>
>
> It seems to be up and running.
>  docker container ps
> CONTAINER IDIMAGE  COMMAND 
>  CREATED STATUSPORTS 
> a5b51342ccc0linforpros/mayanedms:2.7   "entrypoint.sh mayan"16 
> minutes ago  Up 16 minutes (healthy)   0.0.0.0:80->80/tcp
> a8019f91ac72healthcheck/rabbitmq   "docker-entrypoint..."   17 
> minutes ago  Up 16 minutes (healthy)   4369/tcp, 5671-5672/tc
> 17f22498fa1fhealthcheck/redis  "docker-entrypoint..."   17 
> minutes ago  Up 16 minutes (healthy)   6379/tcp  
> 10384ced7876healthcheck/postgres   "docker-entrypoint..."   17 
> minutes ago  Up 16 minutes (healthy)   5432/tcp
>
> The question is however if that was the right way to do it.
> Could anyone steer me to soe tools how to double check if this version is 
> not missing some functionality, like python3 capabilities which were 
> mentioned in the new version 2.7
>
> Thank
> Lin
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2077] Re: Document Type/Cabinets on document list

[Roberto Rosario]

Good idea. Will try text accents and/or icons to see what works without 
crowding the widget too much. Thanks.

On Tuesday, September 5, 2017 at 9:57:20 AM UTC-4, LeVon Smoker wrote:
>
>
> I like the fact that a documents' Cabinets are shown below the thumbnail. 
> It would be nice if they could be differentiated so that there is a visual 
> indication (other than the position of the text). Maybe italicizing or 
> bolding the document type would be helpful - and/or adding hover text.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2074] Re: worker and beat can't write to /tmp/mayan_locks.tmp using the advanced deployment instructions

[Roberto Rosario]

Started a new repository for testing the deployment 
here: https://gitlab.com/mayan-edms/mayan-edms-vagrant

It is using Vagrant to test a bash script that does the advanced 
deployment. The bash script that could be run almost verbatim on a 
production system.

On a side note, if this bash script if made more intelligent by detecting 
the host OS, the same script could be updated to do the deployment on 
different OS (Ubuntu, Fedora, Arch, MacOS). 

A further advantage is that it could be executed from the web directly, 
something like:

wget -O - https://bootstrap.mayan-edms.com | sudo sh


On Thursday, August 31, 2017 at 8:59:09 PM UTC-4, Hans Fritz wrote:
>
> Opened an issue: https://gitlab.com/mayan-edms/mayan-edms/issues/427
>
> Thanks!
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2073] Re: Sort cabinets by alphabetically

[Roberto Rosario]

The list of cabinets need to be sorted in the view. This appears to be 
because Django MPTT return a crafted QuerySet for root nodes that doesn't 
obey the ordering specified in the model's Meta options 
(https://django-mptt.github.io/django-mptt/models.html#root-nodes). 
Implemented 
here: 
https://gitlab.com/mayan-edms/mayan-edms/commit/9fbcfcf00f5a98d4d7e1d3fed6541b433ee0b124

Added the same solution to the list of a document's cabinets membership 
here: 
https://gitlab.com/mayan-edms/mayan-edms/commit/99dc39783c364185457b781ecea68e6f4b6aabeb

This will be available in version 2.7.2.

On Sunday, September 3, 2017 at 6:56:31 AM UTC-4, Thomas Plotkowiak wrote:
>
> I would want my cabinets to be sorted alphabetically so i can find them 
> better. Where do i change that in the code?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2071] Re: Transformations Auto Rotate (bug)

[Roberto Rosario]

I ran the file through the command `pdfinfo` and it reports that the pages 
are rotate by 270 degrees. Mayan is adding a 90 degrees rotation 
transformation to compensate. However when I view the PDF with xpdf and 
evince or extract the PDF pages by hand using pdftoppm or ghoscript, they 
are not rotated, they come out straight (portrait). I tried the same with 
the PDF you included in issue 387 
(https://gitlab.com/mayan-edms/mayan-edms/issues/387) which also reports a 
rotation of 270 degrees. With this document, viewed or extracted pages have 
indeed a rotation of 270 degrees and show in landscape format. 

I'm uncertain if the PDF metadata reporting a 270 degrees rotation in the 
latest PDF (AUGUST 30 2017 2017-01042.pdf) is incorrect or that the 
extraction and viewers tools are all compensating automatically. Both PDF 
seem to be produced by the same equipment: Xerox WorkCentre 7845 but the 
first document (2016_Pumper_Test_Records.pdf) appears to be single pages 
that were later merged using a PDF merge tool.

More tests using different tools is required to determine which situation 
is the correct one: 1) the rotation information is wrong, 2) the tools all 
compensate for rotation when extracting images or viewing and it is not 
necessary for Mayan to add a transformation, 3) the merge tool used to 
compose the first PDF document scrambled the rotation metadata or rotated 
the pages without updating the rotation metadata.

On Friday, September 1, 2017 at 8:21:55 AM UTC-4, David Kornahrens wrote:
>
> Roberto,
> Here is one of the documents.  I've noticed they are rotating coming from 
> the source (we use printer to IMAP email to pick up the files).
>
> Thanks,
> David
>
> On Tuesday, August 29, 2017 at 12:05:32 PM UTC-4, David Kornahrens wrote:
>>
>> We are having documents self-rotate themselves 90 degrees and I'm not 
>> sure why.  I'm having to manually remove the transformations from each 
>> document and then resubmit them for OCR.
>>
>> Any ideas?
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2066] Re: worker and beat can't write to /tmp/mayan_locks.tmp using the advanced deployment instructions

[Roberto Rosario]

Thanks for testing. Please do so to track the issue. Thanks.

On Thursday, August 31, 2017 at 5:58:42 PM UTC-4, Hans Fritz wrote:
>
> I did but it fails because /tmp/mayan_locks.tmp is still owned by root. 
> I'm not sure which part of the application generates it. The only 
> workaround I found is to create /tmp/mayan_locks.tmp ahead of time and 
> chown www-data:www-data ahead of time. I'll open an issue on GitLab.
>
> On Thursday, 31 August 2017 16:43:44 UTC-4, Roberto Rosario wrote:
>>
>> You are correct. It is an error in the documentation. Under the Docker 
>> image everything runs as root to be able to access staging and watch folder 
>> files (due to user ownership issues with Docker). For advanced deployments 
>> where users have more control makes sense to have everything running under 
>> a non privileged user like www-data. Try running the uwsgi process as that 
>> user. 
>>
>> On Thursday, August 31, 2017 at 9:43:07 AM UTC-4, Hans Fritz wrote:
>>>
>>> No this is still a problem after all. The lockfile is created by root 
>>> and is not readable to www-data. I'm guessing program:mayan-uwsgi creates 
>>> it (runs as root) and the worker + beat try to write to it but can't.
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2064] Re: Transformations Auto Rotate (bug)

[Roberto Rosario]

I need one of the actual PDF files to upload it locally and debug the 
rotation detection. If these are produced by a specific equipment you can 
scan a dummy test page (like the one Ubuntu of Windows produces to test a 
printer) and attach it to a the reply.

On Thursday, August 31, 2017 at 9:11:58 AM UTC-4, David Kornahrens wrote:
>
> Roberto, 
> See attached screen shots.
>
>
>
> On Wednesday, August 30, 2017 at 4:55:14 AM UTC-4, Roberto Rosario wrote:
>>
>> Can you provide a sample document (no confidential or private 
>> information) to test and debug the issues?
>>
>> On Tuesday, August 29, 2017 at 12:05:32 PM UTC-4, David Kornahrens wrote:
>>>
>>> We are having documents self-rotate themselves 90 degrees and I'm not 
>>> sure why.  I'm having to manually remove the transformations from each 
>>> document and then resubmit them for OCR.
>>>
>>> Any ideas?
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2063] Re: worker and beat can't write to /tmp/mayan_locks.tmp using the advanced deployment instructions

[Roberto Rosario]

You are correct. It is an error in the documentation. Under the Docker 
image everything runs as root to be able to access staging and watch folder 
files (due to user ownership issues with Docker). For advanced deployments 
where users have more control makes sense to have everything running under 
a non privileged user like www-data. Try running the uwsgi process as that 
user. 

On Thursday, August 31, 2017 at 9:43:07 AM UTC-4, Hans Fritz wrote:
>
> No this is still a problem after all. The lockfile is created by root and 
> is not readable to www-data. I'm guessing program:mayan-uwsgi creates it 
> (runs as root) and the worker + beat try to write to it but can't.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2062] Re: Let's encrypt for Mayan Docker image?

[Roberto Rosario]

I don't have any experience with Let's Encrypt. It there an official Docker 
image for Let's Encrypt?
If there were the testing docker-compose.yml file could be updated to use 
it.

On Monday, August 14, 2017 at 12:17:04 AM UTC-4, Lin Pro wrote:
>
> Hello, what would be the best solution to use for "let's encrypt" so that 
> Mayan speaks https?
> Should a separate Docker image be used for let's encrypt (like zeroSSL 
> docker img) or should we use something from within the mayan docker image 
> by modifying the existing Mayan dockefile?
>
> Thanks for any hints
> Lin
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2060] Re: docker compose definition for staging and watch folders for mayan edms?

[Roberto Rosario]

Seems to be correct. I'll help you test it once version 2.7.1 is out and I 
start working on updating the Docker image.

On Sunday, August 20, 2017 at 9:58:05 PM UTC-4, Lin Pro wrote:
>
> Further reading docker forums I found the following:
> driver: local
> driver_opts:
>   o: bind
>   type: none
>   device:/path/to/dir/on/host
>
> Has anybody tried that with mayan to get staging or watch folders working 
> through compose.yml?
>
> Regards
> Lin
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2060] Re: Mayan EDMS's immediate future

[Roberto Rosario]

The OCR app will have to be removed before version 3.0. The improved OCR 
app (zones & barcodes) will be available as a separate app. The current app 
can be extracted and packaged as Jesaja suggests. As a compromise the OCR 
was split into two in version 2.7, and while there will be no OCR by 
default, text from PDF files will still be available using parsing via the 
new `document_parsing` app. 

On Wednesday, August 30, 2017 at 4:24:12 PM UTC-4, Hans Fritz wrote:
>
> I'm sorry, I still don't get it: Does it mean that the newer version 
> doesn't OCR PDF documents anymore out of the box? Or does it mean that 
> basic OCR is there as it has always been, and to get the more advanced zone 
> OCR one would have to buy the plugin?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2059] Re: Trouble with debug/runserver on 2.6.4

[Roberto Rosario]

Give this a try without the ldap or MySQL libraries:

from __future__ import absolute_import

from django.utils.encoding import force_text

try:
from .local import *  # NOQA
except ImportError as exception:
# Python 2 and 3 exception messages
if force_text(exception) != 'No module named local' and 
force_text(exception) != 'No module named \'mayan.settings.local\'':
raise
from .base import *  # NOQA

Ported from 
here: 
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/smart_settings/classes.py#L27


On Thursday, August 31, 2017 at 4:20:39 PM UTC-4, Roberto Rosario wrote:
>
> The behavior is caused by this: 
> https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/settings/__init__.py
>
> It is meant to allow Mayan to continue executing even if there is no 
> local.py (such as when running the createsettings or initialsetup 
> commands). Raising an error would not allow the normal flow to happen. 
> Python groups all import exception under ImportException regardless of what 
> cause a module to import. The best I've come up with is to examine the text 
> of the exception to try to find out why it was raised (example: 
> https://gitlab.com/mayan-edms/mayan-edms-docker/blob/master/etc/mayan/settings/__init__.py#L49).
>  
> This is a crude solution, but Python doesn't offer anything else that I 
> know of. Best compromise would be to display a warning and keep the 
> execution going. Thoughts?
>
> On Thursday, August 31, 2017 at 9:11:30 AM UTC-4, MacRobb Simpson wrote:
>>
>> First off, sorry for taking so long for a response.
>>
>> Doing exactly that... worked.
>> Upon troubleshooting, the only thing different between this 'clean' copy 
>> and mine was the local.py config file, where I had a few extra settings - 
>> Mysql DB setup for the DB, ldap for authentication.
>> What I eventually found is that, if you don't have the Mysql or ldap 
>> packages installed vin your virtualenv, instead of crashing Mayan simply... 
>> ignores the entire local.py file?
>>
>> I was able to definitively prove this - add "import ldap" to the 
>> local.py, and static files aren't served. Remove it(or install the 
>> package), and they are.
>>
>> Anyway, I hope this helps someone. This is very much unlike any other 
>> Python application I've ever seen when it comes to that behavior.
>>
>> Thanks,
>>
>> -Rob 
>>
>>
>> On Thursday, August 24, 2017 at 11:57:50 AM UTC-7, Roberto Rosario wrote:
>>>
>>> Hi,
>>>
>>> I was not able to reproduce your issue. Error 500 for static media means 
>>> the DEBUG=True statement is not being picked up by Django. Make sure you 
>>> are editing the local.py inside the virtualenv and not in the root 
>>> installation of Python (your path has an initial '/'). Unlikely but just in 
>>> case.
>>>
>>> Also make sure there are no other hanged processes using:
>>>
>>> ps x a| grep 'mayan'
>>>
>>> Sometimes previous runserver commands can remain in a Linux zombie 
>>> process.
>>>
>>> Finally, try this exactly as typed and check static media to discard any 
>>> library difference with the OS.
>>>
>>> cd /tmp
>>> virtualenv venv
>>> source venv/bin/activate
>>> pip install mayan-edms==2.6.4
>>> mayan-edms.py initialsetup
>>> echo "DEBUG=True" >> 
>>> venv/lib/python2.7/site-packages/mayan/settings/local.py
>>> mayan-edms.py runserver
>>>
>>> Browse to localhost:8000
>>>
>>> Check static files directly: 
>>> http://127.0.0.1:8000/static/appearance/css/base.css
>>>
>>> Let me know how it goes.
>>>
>>> On Tuesday, August 22, 2017 at 10:55:03 AM UTC-4, MacRobb Simpson wrote:
>>>>
>>>> Hello,
>>>>
>>>> I'm running into a little bit of trouble getting static files served 
>>>> using the 'mayan-edms.py runserver' command I used in earlier versions.
>>>>
>>>> My goal is to basically have it working like I did in 2.1 - I simply 
>>>> run the 'runserver' command, and I have a development environment running; 
>>>> each load of a file is logged to the console and everything is great!
>>>>
>>>> Currently, what I have is it serving the main content, but no static 
>>>> files - all static requests return 500 errors.
>>>>
>>>> My setup is as follows:
>>>> 1. Deb

[Mayan EDMS: 2058] Re: Trouble with debug/runserver on 2.6.4

[Roberto Rosario]

The behavior is caused by 
this: 
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/settings/__init__.py

It is meant to allow Mayan to continue executing even if there is no 
local.py (such as when running the createsettings or initialsetup 
commands). Raising an error would not allow the normal flow to happen. 
Python groups all import exception under ImportException regardless of what 
cause a module to import. The best I've come up with is to examine the text 
of the exception to try to find out why it was raised 
(example: 
https://gitlab.com/mayan-edms/mayan-edms-docker/blob/master/etc/mayan/settings/__init__.py#L49).
 
This is a crude solution, but Python doesn't offer anything else that I 
know of. Best compromise would be to display a warning and keep the 
execution going. Thoughts?

On Thursday, August 31, 2017 at 9:11:30 AM UTC-4, MacRobb Simpson wrote:
>
> First off, sorry for taking so long for a response.
>
> Doing exactly that... worked.
> Upon troubleshooting, the only thing different between this 'clean' copy 
> and mine was the local.py config file, where I had a few extra settings - 
> Mysql DB setup for the DB, ldap for authentication.
> What I eventually found is that, if you don't have the Mysql or ldap 
> packages installed vin your virtualenv, instead of crashing Mayan simply... 
> ignores the entire local.py file?
>
> I was able to definitively prove this - add "import ldap" to the local.py, 
> and static files aren't served. Remove it(or install the package), and they 
> are.
>
> Anyway, I hope this helps someone. This is very much unlike any other 
> Python application I've ever seen when it comes to that behavior.
>
> Thanks,
>
> -Rob 
>
>
> On Thursday, August 24, 2017 at 11:57:50 AM UTC-7, Roberto Rosario wrote:
>>
>> Hi,
>>
>> I was not able to reproduce your issue. Error 500 for static media means 
>> the DEBUG=True statement is not being picked up by Django. Make sure you 
>> are editing the local.py inside the virtualenv and not in the root 
>> installation of Python (your path has an initial '/'). Unlikely but just in 
>> case.
>>
>> Also make sure there are no other hanged processes using:
>>
>> ps x a| grep 'mayan'
>>
>> Sometimes previous runserver commands can remain in a Linux zombie 
>> process.
>>
>> Finally, try this exactly as typed and check static media to discard any 
>> library difference with the OS.
>>
>> cd /tmp
>> virtualenv venv
>> source venv/bin/activate
>> pip install mayan-edms==2.6.4
>> mayan-edms.py initialsetup
>> echo "DEBUG=True" >> 
>> venv/lib/python2.7/site-packages/mayan/settings/local.py
>> mayan-edms.py runserver
>>
>> Browse to localhost:8000
>>
>> Check static files directly: 
>> http://127.0.0.1:8000/static/appearance/css/base.css
>>
>> Let me know how it goes.
>>
>> On Tuesday, August 22, 2017 at 10:55:03 AM UTC-4, MacRobb Simpson wrote:
>>>
>>> Hello,
>>>
>>> I'm running into a little bit of trouble getting static files served 
>>> using the 'mayan-edms.py runserver' command I used in earlier versions.
>>>
>>> My goal is to basically have it working like I did in 2.1 - I simply run 
>>> the 'runserver' command, and I have a development environment running; each 
>>> load of a file is logged to the console and everything is great!
>>>
>>> Currently, what I have is it serving the main content, but no static 
>>> files - all static requests return 500 errors.
>>>
>>> My setup is as follows:
>>> 1. Debian x64 system
>>> 2. Mayan is installed in a virtualenv using pip ("pip install 
>>> mayan-edms").
>>> 3. I've created a 'local.py' file in 
>>> '/lib/python2.7/site-packages/mayan/settings/' and added 'DEBUG=True', as 
>>> shown here: https://gitlab.com/mayan-edms/mayan-edms/issues/368
>>> 4. I've verified that my local.py file is being picked up - I've deleted 
>>> all the .pyc files in that directory, and when I run the runserver command, 
>>> it creates 'local.pyc' again.
>>>
>>> When I run it using the runserver command, I get no errors, and no 
>>> logging of anything in the console, not even the browser request that 
>>> brings me to the login screen(which obviously returns 200 in the browser).
>>> (It *is* being loaded from this instance of Mayan, however - killing the 
>>> runserver command, the page doesn't load at all, as expected).
>>>
>>> Any ideas on how to make debug mode work?
>>>
>>> Thanks,
>>>
>>> -Rob
>>>
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2057] Re: Upload wizard question

[Roberto Rosario]

Managed to get an ACL edit action but it is static, can effect one specific 
object and not the document receiving the state change. As the workflow 
action matures I'll port the HTTP POST templating (which allows dynamic 
objects) to the a new dynamic object ACL edit actions.

On Friday, August 25, 2017 at 4:24:20 PM UTC-4, Roberto Rosario wrote:
>
> I'll try to squeeze an ACL edit workflow action (like this one for tags 
> https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/tags/workflow_actions.py)
>  
> in time for the next release.
>
> On Aug 25, 2017 4:21 PM, "Roberto Rosario" <
> roberto.rosario.gonza...@gmail.com> wrote:
>
>> Not at the moment. The only way right now to do what you need would be to 
>> subscribe to the post_save signal of the Cabinet model. You need to write a 
>> handler in your app's handlers.py file and register in your apps.py file to 
>> be a receiver of the post_save signal from the sender Cabinet. In your 
>> handler function you will code the interaction you need but it will be a 
>> hard coded interaction. 
>>
>> The new workflow triggers and actions features being added at the moment 
>> are geared for that purpose but it is still in development. 
>>
>> On Aug 25, 2017 4:12 PM, "LeVon Smoker"  wrote:
>>
>>> Thanks. Is there a "good" way to perform a task automatically when a 
>>> document is added or removed from a cabinet? I'd like to retrieve the role 
>>> of the cabinet and add an acl for that role to the document.
>>>
>>> On Thursday, August 24, 2017 at 3:01:13 PM UTC-4, Roberto Rosario wrote:
>>>>
>>>> Great! Yes, that is the workaround at the moment. Django's Wizard view 
>>>> was never intended for that and I'm expecting several challenges when the 
>>>> time comes to rewrite it.
>>>>
>>>> On Wednesday, August 16, 2017 at 8:39:35 AM UTC-4, LeVon Smoker wrote:
>>>>>
>>>>> Awesome. Thanks. I did figure out a hack to basically replace Tags in 
>>>>> the Upload wizard with Cabinets.
>>>>>
>>>>> On Friday, August 11, 2017 at 10:56:46 AM UTC-4, LeVon Smoker wrote:
>>>>>>
>>>>>> Roberto,
>>>>>>
>>>>>> Is there a release target date for the document upload wizard 
>>>>>> refactor? Specifically, I'm looking for the ability to add cabinets 
>>>>>> during 
>>>>>> upload.
>>>>>>
>>>>>> In the mean time, what's the best way to hack in cabinets on the 
>>>>>> upload wizard?
>>>>>>
>>>>>> Thanks,
>>>>>> LeVon Smoker
>>>>>>
>>>>>
>>>>> ...
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2051] Mayan EDMS version 2.7 released

[Roberto Rosario]

Version 2.7 is available for download from Python Package Index 
(https://pypi.python.org/pypi/mayan-edms/2.7). Docker image available soon.

Highlights for this version:


   - Preliminary support for Python 3.
   - Improvements for 3rd party app customization. Default main menus as 
   well as dashboard items can now be disabled. Support for unlimited 
   dashboard was added too.
   - Converter improvements. It is possible to change the internal image 
   file format used. By default the format is JPEG. The DPI value for images 
   made out of PDF file pages can also be changed from the default 300 DPI.
   - Workflow refactor. This version includes initial support for workflow 
   triggers and workflow actions. Workflow triggers allow a workflow to 
   transition from states when a specific system of document event occurs. 
   Actions allow programming a system action when a workflow enters or leaver 
   a workflow state. This feature allow coding "if this happens, then do this" 
   style automation using the workflow engine. Support for rendering workflow 
   as image previews was added.
   - The OCR app was split into two different apps. One app now only does 
   OCR and the other parses the text content of documents. The parsed text and 
   the OCRed text of a document are available independently.
   - Previously document version were just listed in a table. Now document 
   version are rendered, are interactive and can be viewed in the same manner 
   and with the same widgets of documents.
   - 8 new events are now logged and tracked, the total number of events 
   logged is now 21. The new events are: 
  - Document version OCR finished
  - Document version submitted for OCR
  - Document version parsing finished
  - Document version submitted for parsing
  - Tag attached to document
  - Tag removed from document
  - Document added to cabinet
  - Document removed from cabinet
   - Changing a document's type no longer deletes common metadata that is 
   found in the old and new document type.
   - The tag attach and remove action now required the document tag attach 
   and remove permssions respectively instead of just the tag view permission.
   - Now that Cabinets code is stable and mature, all the code for the 
   previous Folders app has been removed.

For the complete release notes see: 
http://mayan.readthedocs.io/en/2.7/releases/2.7.html

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2049] Re: Mayan EDMS's immediate future

[Roberto Rosario]

It is perfectly acceptable, you have that freedom under the license. In 
Django this has been several times 
(https://github.com/django/django-formtools). Check the other projects 
under the Mayan organization for examples on how to package you own app: 
https://gitlab.com/mayan-edms

The documentation chapter on the 
matter: http://docs.mayan-edms.com/en/latest/topics/development.html

On Wednesday, August 30, 2017 at 10:05:48 AM UTC-4, Jesaja Everling wrote:
>
> If it is the case that the zone OCR app will not be freely available to 
> the public, is it OK when someone creates an app called something like 
> "Mayan Simple OCR" to make the classic OCR engine installable?
>
> On Wed, Aug 30, 2017 at 7:29 PM, Hans Fritz  
> wrote:
>
>> Hi Roberto,
>>
>> I'm not sure I understand the implications of removing the current OCR 
>> app. Does it mean that from 2.7 onwards, Mayan won't have any OCR 
>> capabilities at all anymore? What are the implications of the zone OCR app 
>> being separate? Will it still be available freely for anyone who wants to 
>> add it or will it be paid, closed source leaving the community without any 
>> OCR?
>>
>>
>> On Tuesday, 22 August 2017 01:49:05 UTC-4, Roberto Rosario wrote:
>>>
>>> From the blog: https://www.mayan-edms.com/post/post-crowdfunding/
>>>
>>>
>>> Two days after posting the blog about the unsuccessful crowdfunding for 
>>>> the zone OCR support, a group of companies stepped forward with the 
>>>> interest of investing to get this feature done and keep the project active 
>>>> for a while. However, as with any investment (including crowdfunding), 
>>>> there are some obligations.
>>>>
>>>> For companies having a competitive edge is a necessity. Therefore a 
>>>> condition for the funding is that the zone OCR support must be added as a 
>>>> separate app.
>>>>
>>>> Researching the list of changes needed to get this implemented, there 
>>>> is the matter of the database migrations. There is interdependency in the 
>>>> migration history of the OCR and other apps, this means that it is not 
>>>> possible to have two OCR apps installed at the same time. For the Zone OCR 
>>>> app to work, the current OCR app must be removed. Mayan EDMS version 2.7 
>>>> will be the last version to include the current OCR app.
>>>>
>>>> This was not an easy decision to make. No doubt many will not agree 
>>>> with it, but it was the right decision to keep the project alive.
>>>>
>>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mayan EDMS" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mayan-edms+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2046] Re: Transformations Auto Rotate (bug)

[Roberto Rosario]

Can you provide a sample document (no confidential or private information) 
to test and debug the issues?

On Tuesday, August 29, 2017 at 12:05:32 PM UTC-4, David Kornahrens wrote:
>
> We are having documents self-rotate themselves 90 degrees and I'm not sure 
> why.  I'm having to manually remove the transformations from each document 
> and then resubmit them for OCR.
>
> Any ideas?
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2043] Re: Upload wizard question

[Roberto Rosario]

I'll try to squeeze an ACL edit workflow action (like this one for tags
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/tags/workflow_actions.py)
in time for the next release.

On Aug 25, 2017 4:21 PM, "Roberto Rosario" <
roberto.rosario.gonza...@gmail.com> wrote:

> Not at the moment. The only way right now to do what you need would be to
> subscribe to the post_save signal of the Cabinet model. You need to write a
> handler in your app's handlers.py file and register in your apps.py file to
> be a receiver of the post_save signal from the sender Cabinet. In your
> handler function you will code the interaction you need but it will be a
> hard coded interaction.
>
> The new workflow triggers and actions features being added at the moment
> are geared for that purpose but it is still in development.
>
> On Aug 25, 2017 4:12 PM, "LeVon Smoker"  wrote:
>
>> Thanks. Is there a "good" way to perform a task automatically when a
>> document is added or removed from a cabinet? I'd like to retrieve the role
>> of the cabinet and add an acl for that role to the document.
>>
>> On Thursday, August 24, 2017 at 3:01:13 PM UTC-4, Roberto Rosario wrote:
>>>
>>> Great! Yes, that is the workaround at the moment. Django's Wizard view
>>> was never intended for that and I'm expecting several challenges when the
>>> time comes to rewrite it.
>>>
>>> On Wednesday, August 16, 2017 at 8:39:35 AM UTC-4, LeVon Smoker wrote:
>>>>
>>>> Awesome. Thanks. I did figure out a hack to basically replace Tags in
>>>> the Upload wizard with Cabinets.
>>>>
>>>> On Friday, August 11, 2017 at 10:56:46 AM UTC-4, LeVon Smoker wrote:
>>>>>
>>>>> Roberto,
>>>>>
>>>>> Is there a release target date for the document upload wizard
>>>>> refactor? Specifically, I'm looking for the ability to add cabinets during
>>>>> upload.
>>>>>
>>>>> In the mean time, what's the best way to hack in cabinets on the
>>>>> upload wizard?
>>>>>
>>>>> Thanks,
>>>>> LeVon Smoker
>>>>>
>>>>
>>>> ...
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2042] Re: Upload wizard question

[Roberto Rosario]

Not at the moment. The only way right now to do what you need would be to
subscribe to the post_save signal of the Cabinet model. You need to write a
handler in your app's handlers.py file and register in your apps.py file to
be a receiver of the post_save signal from the sender Cabinet. In your
handler function you will code the interaction you need but it will be a
hard coded interaction.

The new workflow triggers and actions features being added at the moment
are geared for that purpose but it is still in development.

On Aug 25, 2017 4:12 PM, "LeVon Smoker"  wrote:

> Thanks. Is there a "good" way to perform a task automatically when a
> document is added or removed from a cabinet? I'd like to retrieve the role
> of the cabinet and add an acl for that role to the document.
>
> On Thursday, August 24, 2017 at 3:01:13 PM UTC-4, Roberto Rosario wrote:
>>
>> Great! Yes, that is the workaround at the moment. Django's Wizard view
>> was never intended for that and I'm expecting several challenges when the
>> time comes to rewrite it.
>>
>> On Wednesday, August 16, 2017 at 8:39:35 AM UTC-4, LeVon Smoker wrote:
>>>
>>> Awesome. Thanks. I did figure out a hack to basically replace Tags in
>>> the Upload wizard with Cabinets.
>>>
>>> On Friday, August 11, 2017 at 10:56:46 AM UTC-4, LeVon Smoker wrote:
>>>>
>>>> Roberto,
>>>>
>>>> Is there a release target date for the document upload wizard refactor?
>>>> Specifically, I'm looking for the ability to add cabinets during upload.
>>>>
>>>> In the mean time, what's the best way to hack in cabinets on the upload
>>>> wizard?
>>>>
>>>> Thanks,
>>>> LeVon Smoker
>>>>
>>>
>>> ...

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2040] CONVERT EML TO PDF

[Roberto Rosario]

It seems Python can handle .eml files natively 
(https://stackoverflow.com/questions/31392361/how-to-read-eml-file-in-python#31392574)
 
so it could be possible to write a renderer for them in the future. For the 
moment Mark's suggestion is the most direct. I don't have experience with 
CUPS but if it can print to PDF, a bridge setup could be done to also 
upload the PDF. Something like "Print to Mayan". Is it possible to execute 
a bash file after printing?

On Wednesday, August 23, 2017 at 10:47:30 AM UTC-4, Mark Phillips wrote:
>
> Most printer installation include printing to pdf. You could also try cups 
> to print to a pdf file. The attachments you will have to download.
>
> Mark
>
> On Wed, Aug 23, 2017 at 1:10 AM, C V  wrote:
>
>> I would use mayan edms to handle emails as well, there are some open 
>> source software that convert emails and attachment (eml files) to pdf ?
>> Thanks for the help.
>>
>> Fabio
>>
>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Mayan EDMS" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to mayan-edms+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2039] Re: Upload wizard question

[Roberto Rosario]

Great! Yes, that is the workaround at the moment. Django's Wizard view was 
never intended for that and I'm expecting several challenges when the time 
comes to rewrite it.

On Wednesday, August 16, 2017 at 8:39:35 AM UTC-4, LeVon Smoker wrote:
>
> Awesome. Thanks. I did figure out a hack to basically replace Tags in the 
> Upload wizard with Cabinets.
>
> On Friday, August 11, 2017 at 10:56:46 AM UTC-4, LeVon Smoker wrote:
>>
>> Roberto,
>>
>> Is there a release target date for the document upload wizard refactor? 
>> Specifically, I'm looking for the ability to add cabinets during upload.
>>
>> In the mean time, what's the best way to hack in cabinets on the upload 
>> wizard?
>>
>> Thanks,
>> LeVon Smoker
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2037] Re: Menu item unbinding

[Roberto Rosario]

Hi,

Don't delete your messages, your implementation was correct. Also leave the 
messages so others can follow your code.

On Wednesday, August 16, 2017 at 12:56:34 PM UTC-4, LeVon Smoker wrote:
>
> Roberto,
>
> Is it possible to unbind a menu item based on the user's permissions? I 
> have unbound some but has has removed items globally.
>
> Thanks.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2037] Re: Trouble with debug/runserver on 2.6.4

[Roberto Rosario]

Hi,

I was not able to reproduce your issue. Error 500 for static media means 
the DEBUG=True statement is not being picked up by Django. Make sure you 
are editing the local.py inside the virtualenv and not in the root 
installation of Python (your path has an initial '/'). Unlikely but just in 
case.

Also make sure there are no other hanged processes using:

ps x a| grep 'mayan'

Sometimes previous runserver commands can remain in a Linux zombie process.

Finally, try this exactly as typed and check static media to discard any 
library difference with the OS.

cd /tmp
virtualenv venv
source venv/bin/activate
pip install mayan-edms==2.6.4
mayan-edms.py initialsetup
echo "DEBUG=True" >> 
venv/lib/python2.7/site-packages/mayan/settings/local.py
mayan-edms.py runserver

Browse to localhost:8000

Check static files 
directly: http://127.0.0.1:8000/static/appearance/css/base.css

Let me know how it goes.

On Tuesday, August 22, 2017 at 10:55:03 AM UTC-4, MacRobb Simpson wrote:
>
> Hello,
>
> I'm running into a little bit of trouble getting static files served using 
> the 'mayan-edms.py runserver' command I used in earlier versions.
>
> My goal is to basically have it working like I did in 2.1 - I simply run 
> the 'runserver' command, and I have a development environment running; each 
> load of a file is logged to the console and everything is great!
>
> Currently, what I have is it serving the main content, but no static files 
> - all static requests return 500 errors.
>
> My setup is as follows:
> 1. Debian x64 system
> 2. Mayan is installed in a virtualenv using pip ("pip install mayan-edms").
> 3. I've created a 'local.py' file in 
> '/lib/python2.7/site-packages/mayan/settings/' and added 'DEBUG=True', as 
> shown here: https://gitlab.com/mayan-edms/mayan-edms/issues/368
> 4. I've verified that my local.py file is being picked up - I've deleted 
> all the .pyc files in that directory, and when I run the runserver command, 
> it creates 'local.pyc' again.
>
> When I run it using the runserver command, I get no errors, and no logging 
> of anything in the console, not even the browser request that brings me to 
> the login screen(which obviously returns 200 in the browser).
> (It *is* being loaded from this instance of Mayan, however - killing the 
> runserver command, the page doesn't load at all, as expected).
>
> Any ideas on how to make debug mode work?
>
> Thanks,
>
> -Rob
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2031] Mayan EDMS's immediate future

[Roberto Rosario]

>From the blog: https://www.mayan-edms.com/post/post-crowdfunding/


Two days after posting the blog about the unsuccessful crowdfunding for the 
> zone OCR support, a group of companies stepped forward with the interest of 
> investing to get this feature done and keep the project active for a while. 
> However, as with any investment (including crowdfunding), there are some 
> obligations.
>
> For companies having a competitive edge is a necessity. Therefore a 
> condition for the funding is that the zone OCR support must be added as a 
> separate app.
>
> Researching the list of changes needed to get this implemented, there is 
> the matter of the database migrations. There is interdependency in the 
> migration history of the OCR and other apps, this means that it is not 
> possible to have two OCR apps installed at the same time. For the Zone OCR 
> app to work, the current OCR app must be removed. Mayan EDMS version 2.7 
> will be the last version to include the current OCR app.
>
> This was not an easy decision to make. No doubt many will not agree with 
> it, but it was the right decision to keep the project alive.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2021] Mayan EDMS crowdfunding is over

[Roberto Rosario]

Repost from the web: 
https://www.mayan-edms.com/post/first-crowdfunding-over/


Sadly, the attempt to use crowdfunding to add the zone OCR feature was not 
> successful.
>
> The original goal was to raise $720 USD to hire a frontend developer 
> knowledgeable in the topic, while I would work on the backend side of 
> things. The final result for the campaign was $330 or 46% of the goal. I’m 
> very grateful to the backers of the campaign:
>
>- Matthias Löblich
>- Douglas Van Es
>- Marek Stopka
>- Jesaja Everling
>- Matthias Sieke
>- Korbinian Preisler
>
> Since the campaign was a fixed goal campaign, we get nothing if the goal 
> was not reached. The running time for the campaign was 30 days.
>
> What went wrong? Hard to say. The analytics showed increased traffic to 
> the site for the 30 days of the campaign. A quick search shows good SEO and 
> we even got several extra thousand visits just from the Hacker News post. 
> The exposure was good. Given the traffic, even with a worst case scenario 
> of 1% conversion rate, there should have been enough backing to reach the 
> funding goal.
>
> The growth and the amount of work the project requires mean that a source 
> of reliable and adequate funding needs to be created/found to keep the 
> project sustainable. This is not the first attempt to raise funds for the 
> project that has failed.
>
> It is not possible to continue devoting the current amount of time and 
> routing resources from my commercial ventures to the project. It is with a 
> heavy heart that I must accept that the future of the Mayan EDMS is 
> uncertain at the moment.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2018] Re: Upload wizard question

[Roberto Rosario]

The wizard refactor is scheduled for version 3.0 because it will be 
backwards incompatible. Use the Tag step as an 
example: 
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/sources/wizards.py#L41
You need to modify the DocumentCreateWizard wizard class to add the step to 
it. The refactor aims to extract the steps from the wizard as a separate 
WizardStep class. The aim is to allow wizard steps to be added (or even 
removed) in the same way links, permissions, and dashboard widgets can be 
added by any app.

On Friday, August 11, 2017 at 11:36:08 AM UTC-4, David Kornahrens wrote:
>
> I second this request.  Not fully understanding the index feature, 
> cabinets is our best way to organize data.
>
> On Friday, August 11, 2017 at 10:56:46 AM UTC-4, LeVon Smoker wrote:
>>
>> Roberto,
>>
>> Is there a release target date for the document upload wizard refactor? 
>> Specifically, I'm looking for the ability to add cabinets during upload.
>>
>> In the mean time, what's the best way to hack in cabinets on the upload 
>> wizard?
>>
>> Thanks,
>> LeVon Smoker
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2016] Re: Rebuilding Files

[Roberto Rosario]

Hi,

You would need to execute the same methods that are called when a new 
document version is 
uploaded: 
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/documents/models.py#L443

Code sample. Disclaimer: Haven't tried this before. Make backups and test 
extensively.

for document_version in DocumentVersion.objects.all():
document_version.update_checksum(save=False)
document_version.update_mimetype(save=False)
document_version.save()
document_version.update_page_count(save=False)
document_version.save()

Document.objects.invalidate_cache()

.update_page_count() will delete the existing pages before introspecting 
the file again. This means anything with a foreign key to document pages 
will be deleted as well (OCR, transformations).

On Friday, August 11, 2017 at 6:06:20 AM UTC-4, Gerrit Van Dyk wrote:
>
> Hi
>
> We have quite a lot of files that was scanned and processed at Grayscale, 
> 300DPI with over 2000 pages.
>
> These files are large in size, with some over 2GB per file.
>
> Our clients has now decided that we can reduce the files in size and use a 
> different compression algorithm.
>
> We now want to run our code on the files that are stored within Mayan. We 
> can do this with ease, but the metadata about file size etc needs to be 
> updated.
>
> How can we trigger an update on the metadata stored within Mayan on amount 
> of pages, file size etc, about a file that already exists?
>
> We do not want to load a new version, but would like to update the current 
> version.
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Mayan EDMS: 2009] Server error when viewing indexes

[Roberto Rosario]

Made some progress on this. The problem is not really with the indexing but 
with this: 
https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/common/mixins.py#L269

It is a solution to allow subclass views to have a method called 
get_queryset while also allowing their super class to have the same method 
without causing an method override. It manipulates Python class MRO (method 
resolution order). For some reason in your instance, this code doesn't 
execute correctly and the call to the get_queryset method ends up calling 
itself until Python detects the recursion and stops it via the RunTimeError 
exception. This is the error manifests in document_indexing/views.py by 
really starts in common/mixins.py. So in a sense your perception of how it 
behaved liked a caching problem was not far from the real cause.

The solution would be to find the cause and fix 
the PreserveGetQuerysetMixin mixin class (a bit experimental) or remove it 
and do proper method overloading on all classes that use the get_queryset 
method. The mixin class was created to prevent security issues where a view 
would bypass the ACL check from the get_queryset method, on purpose or by 
accident. Will have to choose the lesser of two evils to fix this.

On Monday, August 7, 2017 at 1:48:45 PM UTC-4, David Kimmel wrote:
>
> Hey Roberto, 
>
> Since it’s intermittent, it’s pretty tough to write detailed replication 
> steps.  I’ve been keeping an eye on it to see if I could tie a specific 
> action to triggering the problem. 
>
> Today the indexes broke again and I noticed that it didn’t happen until 
> after I moved a document to the trash.  As soon as I did this, all of my 
> indexes started showing the server error page.  I’m going to continue 
> monitoring and see if any other actions trigger this.  Interestingly 
> enough, I’ve been doing a bunch of updates to the metadata today and did 
> not get the error at all.   
>
> Are index updates done differently when moving documents to the trash vs 
> updating metadata? 
>
> This really feels like a caching problem to me, but I honestly don’t know 
> enough about Mayan and Django to know if this is a reasonable assumption. 
>
> Thanks, 
> -- Dave Kimmel 
>davidjkim...@gmail.com 
>
>
>
> > On Aug 2, 2017, at 13:22, Roberto Rosario <
> roberto.rosario.gonza...@gmail.com> wrote: 
> > 
> > Thanks for reporting this and for the debug information. The first step 
> is to try to make it repeatable to find the cause, things that happen 
> sometimes and sometimes not are very hard to track down. I'll try to write 
> a test to replicate this behavior in development. Thank you. 
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2008] Re: Cannot Rebuild Indexes manually (MultipleObjectsReturned)

[Roberto Rosario]

Ah yes! Didn't saw it, thanks!

On Friday, August 11, 2017 at 2:30:44 AM UTC-4, Gerrit Van Dyk wrote:
>
> The line number is from lock_manager/managers.py in check_existing on line 
> 55.
>
> I am running this from the normal Rebuild Indexes on the Tools menu.
>
> On Friday, August 11, 2017 at 3:52:25 AM UTC+2, Roberto Rosario wrote:
>>
>> "get() returned more than one Lock -- it returned 15!" <- That should 
>> not be happening. 
>>
>> Can you share the index template you used that triggers this or a 
>> simplified version with no private information?
>>
>> The locks should be releasing even on errors (
>> https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/document_indexing/models.py#L271
>> ).
>>
>> What line number is the .get() error happening?
>>
>> In the worst case, lock have a default timeout of 30 seconds (
>> https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/lock_manager/settings.py#L19
>> )
>>
>> While the cause of the issue in found and fixed you can force a release 
>> of all lock with the management command (command line):
>>
>> ./manage.py purgelocks
>>
>> To achieve the same from code (from Python) use:
>>
>> from lock_manager.runtime import locking_backend
>> locking_backend.purge_locks()
>>
>>
>> On Thursday, August 10, 2017 at 10:18:02 AM UTC-4, Gerrit Van Dyk wrote:
>>>
>>> Hi,
>>>
>>> When trying to rebuild all indexes, I get the following error.
>>>
>>> Exception Type: MultipleObjectsReturned, Exception Value:get() returned 
>>> more than one Lock -- it returned 15!
>>>
>>> It seems that this error is coming from lock_manager/managers.py in 
>>> check_existing on line 55. 
>>>
>>> existing_lock = self.get(**kwargs)
>>>
>>>
>>> How can I clear these errors, or get rid of the multiple locks.
>>>
>>>
>>> Gerrit
>>>
>>>
>>>
>>>
>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2007] Re: multi tenancy

[Roberto Rosario]

A multi tenant branch was started some time ago to support this natively (
https://gitlab.com/mayan-edms/mayan-edms/commits/feature/multi-tenant). It 
implements an Organization class to handle each tenant's data. It is still 
not complete. The tests for the 300+ views are not yet finished. Feel free 
to work on it if you have the time.

Until native database agnostic multi tenant is finished, a plugin that 
provides tenancy using database schemas is available in the app store: 
https://www.mayan-edms.com/store/

On Friday, August 11, 2017 at 2:37:04 AM UTC-4, Tony Nys wrote:
>
> Ideally in mayan, a concept/class Tenant should be there: where a Tenant 
> has 
> * Id
> * Name
> * External-ID (reference), Unique but optional : eg. the Syneton tenant id
> * StorageCollection: container name used eg. in Azure/AWS/... or local 
> subfolder-name in the 'document_storage' folder
>
> A Group has a FK id to a Tenant
> A documenttype  has a FK id to a Tenant
> A Cabinet  has a FK id to a Tenant
>
> so the tenant is actually a group of groups
>
>
> In a first phase, the FK could just be an optional attribute, 
> In a later phase, ACLs could be assigned to a Tenant,
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2002] Re: docker local.py settings import error

[Roberto Rosario]

This is a problem cause by a design decision of Docker that initializes 
volumes in different ways depending on the type of volume: 
https://gitlab.com/mayan-edms/mayan-edms-docker/issues/6#note_22653707

Until Docker fixes this use only named volumes when deploying the Mayan 
Docker image.

On Friday, August 11, 2017 at 1:47:51 AM UTC-4, Tony Nys wrote:
>
> as I see, the mounted docker folder eg. mayan_data, needs a subfolder 
> "settings".
> Mayan will check if a local.py file exist , and if not do an initial 
> installation and create a local.py file in that folder
>
> But when I start mayan the 2nd time, so the file exists, it gives the error
>
> mayan.settings <208> [ERROR] "() Error importing user's local.py; 
> No module named media.settings.local"
>
> so my local.py is in  /Users/tony/mayan_data/settings
>
> Starting docker:
>
> docker run --name mayanedmspostgresql  -p 80:80 -v 
> /Users/tony/mayan_data/:/var/lib/mayan mayanedms/mayanedms
>
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 2000] Re: Cannot Rebuild Indexes manually (MultipleObjectsReturned)

[Roberto Rosario]

"get() returned more than one Lock -- it returned 15!" <- That should not 
be happening. 

Can you share the index template you used that triggers this or a 
simplified version with no private information?

The locks should be releasing even on errors 
(https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/document_indexing/models.py#L271).

What line number is the .get() error happening?

In the worst case, lock have a default timeout of 30 seconds 
(https://gitlab.com/mayan-edms/mayan-edms/blob/master/mayan/apps/lock_manager/settings.py#L19)

While the cause of the issue in found and fixed you can force a release of 
all lock with the management command (command line):

./manage.py purgelocks

To achieve the same from code (from Python) use:

from lock_manager.runtime import locking_backend
locking_backend.purge_locks()


On Thursday, August 10, 2017 at 10:18:02 AM UTC-4, Gerrit Van Dyk wrote:
>
> Hi,
>
> When trying to rebuild all indexes, I get the following error.
>
> Exception Type: MultipleObjectsReturned, Exception Value:get() returned 
> more than one Lock -- it returned 15!
>
> It seems that this error is coming from lock_manager/managers.py in 
> check_existing on line 55. 
>
> existing_lock = self.get(**kwargs)
>
>
> How can I clear these errors, or get rid of the multiple locks.
>
>
> Gerrit
>
>
>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1999] Re: Bulk Metadata creation

[Roberto Rosario]

Yes, since the indexes are disabled during the metadata update they will 
not update. You can force the rebuild by calling the .rebuild() method of 
each Index model instance.

for index in Index.objects.all():
index.rebuild()

Since this will call the rebuild in a synchronous manner each call will 
block and take a while to complete if the index is big.

You can call the index rebuild as a background task as follows:

from document_indexing.tasks import task_rebuild_index

for index in Index.objects.all():
task_rebuild_index.apply_async(kwargs=dict(index_id=index.pk))


On Thursday, August 10, 2017 at 10:07:40 AM UTC-4, Gerrit Van Dyk wrote:
>
> Hi,
>
> Thanks for your reply.
>
> I have implemented the code as you said, and the errors did disappear.
>
> How do I force an index rebuild after all the changes have been done, as I 
> don't see the changes reflected in the indexes.
>
> Gerrit
>
> On Friday, July 14, 2017 at 7:24:37 PM UTC+2, Roberto Rosario wrote:
>>
>> Hi,
>>
>> The code looks good, the issue is with the indexing that is being 
>> triggered by the metadata updates. What version are you using?
>> The indexing code was rewritten in 2.3 to use less locking.
>>
>> For the time being you can disable the indexes at the start of the code 
>> and re-enable them at the end and it should work.
>>
>> from documents.models import Document
>> from document_indexing.models import Index
>> from metadata.models import MetadataType  # Added
>>
>> class Command(BaseCommand):
>> def handle(self, *args, **options):
>>  Index.objects.update(enabled=False)  # Disable all indexes
>>
>> docs = Document.objects.all()
>> for doc in docs:
>> if doc.metadata.filter(metadata_type__name='field1').exists():
>> md = MetadataType.objects.get(name="field2")
>> doc.metadata.create(metadata_type=md,value="123")
>>
>>  Index.objects.update(enabled=True)  # Enable all indexes
>>
>>
>>
>> On Friday, July 14, 2017 at 10:03:34 AM UTC-4, Gerrit Van Dyk wrote:
>>>
>>> Hi
>>>
>>> I am trying to create a metadata field for documents that has some other 
>>> metadata field.
>>>
>>> When the code is run as a command, it runs most of the time, but then in 
>>> some cases it gets "maximum recursion level reached" with the following 
>>> logs:
>>>
>>> lock_manager.managers <29572> [DEBUG] "acquire_lock() trying to acquire 
>>> lock: document_indexing_task_do_rebuild_all_indexes"
>>>
>>> lock_manager.managers <29572> [DEBUG] "acquire_lock() IntegrityError: 
>>> duplicate key value violates unique constraint "lock_manager_lock_name_key"
>>>
>>> DETAIL:  Key (name)=(document_indexing_task_do_rebuild_all_indexes) 
>>> already exists.
>>>
>>>
>>> What is the correct way of doing bulk metadata updates without running 
>>> into the above problems?
>>>
>>> The code is as follows:
>>>
>>> from documents.models import Document
>>> from metadata.models import MetadataType
>>>
>>> class Command(BaseCommand):
>>> def handle(self, *args, **options):
>>> docs = Document.objects.all()
>>> for doc in docs:
>>> if 
>>> doc.metadata.filter(metadata_type__name='field1').exists():
>>> md = MetadataType.objects.get(name="field2")
>>> doc.metadata.create(metadata_type=md,value="123")
>>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1998] Re: Bug re: EventType model

[Roberto Rosario]

I'm not able to reproduce the issue. Try:

make clean

to delete all .pyc files and make sure only new code is executing.




On Thursday, August 10, 2017 at 2:43:49 PM UTC-4, LeVon Smoker wrote:
>
> In the master branch, the events_eventtype table is not created. (This is 
> a git install of the development branch that I switched over to the master 
> branch.
>
> I checked for the "Events/Event types" model on my pip/2.6.4 install using 
> the url http://example.net/admin/events/eventtype/ and get the following 
> error...
> (in short:
> Exception Value: 
>
> '__proxy__' object has no attribute 'label'
>
> Exception Location: /usr/share/mayan-edms/mayan/apps/events/models.py in 
> __str__, line 21)
> Traceback:
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/core/handlers/exception.py"
>  
> in inner
>   42. response = get_response(request)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  
> in _legacy_get_response
>   249. response = self._get_response(request)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  
> in _get_response
>   217. response = self.process_exception_by_middleware(e, 
> request)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/core/handlers/base.py"
>  
> in _get_response
>   215. response = response.render()
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/response.py"
>  
> in render
>   109. self.content = self.rendered_content
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/response.py"
>  
> in rendered_content
>   86. content = template.render(context, self._request)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/backends/django.py"
>  
> in render
>   66. return self.template.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render
>   208. return self._render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in _render
>   199. return self.nodelist.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render
>   994. bit = node.render_annotated(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render_annotated
>   961. return self.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/loader_tags.py"
>  
> in render
>   174. return compiled_parent._render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in _render
>   199. return self.nodelist.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render
>   994. bit = node.render_annotated(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render_annotated
>   961. return self.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/loader_tags.py"
>  
> in render
>   174. return compiled_parent._render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in _render
>   199. return self.nodelist.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render
>   994. bit = node.render_annotated(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render_annotated
>   961. return self.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/loader_tags.py"
>  
> in render
>   70. result = block.nodelist.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render
>   994. bit = node.render_annotated(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/base.py"
>  
> in render_annotated
>   961. return self.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template/loader_tags.py"
>  
> in render
>   70. result = block.nodelist.render(context)
>
> File 
> "/usr/share/mayan-edms/local/lib/python2.7/site-packages/django/template

[Mayan EDMS: 1996] Re: Limit number of OCR processes

[Roberto Rosario]

Rest of second line:

This causes Celery to execute just one worker process as opposed to one 
process for each CPU core. 

http://docs.celeryproject.org/en/latest/userguide/workers.html#concurrency

On Thursday, August 10, 2017 at 9:26:36 PM UTC-4, Roberto Rosario wrote:
>
> Hi,
>
> You can control the number of OCR processes using the "--concurrency=1" 
> setting of Celery on the worker managing the OCR queue. This causes Celery 
> to executye 
>
> For example (from the Docker image):  
>
> python /usr/local/lib/python2.7/dist-packages/mayan/bin/mayan-edms.py 
> celery --settings=mayan.settings.production worker -Ofair -l ERROR -Q 
> mailing,ocr,tools,statistics -n mayan-worker-slow.%%h --concurrency=1
>
> If you are still running out of memory you can add the --concurrency=1 
> setting to the other workers to control the conversion and display 
> processes.
>
> On Thursday, August 10, 2017 at 1:07:55 PM UTC-4, Mirco Hansen wrote:
>
>> Hi,
>>
>> is there a way to limit the number of OCR processes running at the same 
>> time? If I upload lots of documents the OCR in the background makes Mayan 
>> mostly unusable so I want to limit the number of background jobs.
>>
>> Thanks in advance.
>>
>> Regards
>> Mirco
>>
>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1996] Re: Limit number of OCR processes

[Roberto Rosario]

Hi,

You can control the number of OCR processes using the "--concurrency=1" 
setting of Celery on the worker managing the OCR queue. This causes Celery 
to executye 

For example (from the Docker image):  

python /usr/local/lib/python2.7/dist-packages/mayan/bin/mayan-edms.py 
celery --settings=mayan.settings.production worker -Ofair -l ERROR -Q 
mailing,ocr,tools,statistics -n mayan-worker-slow.%%h --concurrency=1

If you are still running out of memory you can add the --concurrency=1 
setting to the other workers to control the conversion and display 
processes.

On Thursday, August 10, 2017 at 1:07:55 PM UTC-4, Mirco Hansen wrote:

> Hi,
>
> is there a way to limit the number of OCR processes running at the same 
> time? If I upload lots of documents the OCR in the background makes Mayan 
> mostly unusable so I want to limit the number of background jobs.
>
> Thanks in advance.
>
> Regards
> Mirco
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1990] Re: Adding Dashboard Widget

[Roberto Rosario]

Merged a branch I was working on to add support for unlimited dashboards. 
This branch also has support for removing widgets from a dashboard.

Commit: 
https://gitlab.com/mayan-edms/mayan-edms/commit/6ec235afc00daf5258ff1c2049f8091247a453c6

The dashboard widgets are now in a module called dashboard_widgets.py in 
each app. The dashboards are in a module called dashboards.py.
By default on the common app has a dashboard called `dashboard_main`.

For example to remove the "Total documents" dashboard widget use in any app 
apps.py file:

from common.dashboads import dashboard_main 
from documents.dashboard_widgets import widget_total_documents

dashboard_main.remove_widget(widget=widget_total_documents)

This has been merged and will be available in the next release.


On Wednesday, August 9, 2017 at 2:48:52 PM UTC-4, LeVon Smoker wrote:
>
> I got this to work by removing the queryset parameter.
>
> Now I'm wondering how to *remove* specific widgets...
>
> LeVon S.
>
> On Wednesday, August 9, 2017 at 1:39:36 PM UTC-4, LeVon Smoker wrote:
>>
>> I have a custom app (hrcsb_overrides) where I have am keeping my 
>> customizations to Mayan. I added the below code to try to add a widget to 
>> the home page as a shortcut to Cabinets (also to experiment).
>> Cabinet = self.get_model('Cabinet')
>>
>> DashboardWidget(
>> icon='fa fa-folder',
>> queryset=Cabinet.objects.all(),
>> label=_('Cabinets'),
>> link=reverse_lazy('cabinets:cabinet_list')
>> )
>>
>> The call to get_model generates an error
>> LookupError: App 'hrcsb_overrides' doesn't have a 'Cabinet' model.
>>
>>
>> which I understand but I can't figure my way around this. Maybe I'm in 
>> the wrong place...
>>
>> Thanks,
>> LeVon Smoker
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1988] Re: Removing menus

[Roberto Rosario]

Thank you for the reports!

On Wednesday, August 9, 2017 at 8:36:42 AM UTC-4, LeVon Smoker wrote:
>
> Thank you very much. Your support of Mayan is awesome.
>
> On Wednesday, August 9, 2017 at 1:39:10 AM UTC-4, Roberto Rosario wrote:
>>
>> Support added (
>> https://gitlab.com/mayan-edms/mayan-edms/commit/0efbf79fa18bb35407b0c71013810489c2f44b04).
>>  
>> Thanks for the report.
>>
>> On Wednesday, August 9, 2017 at 1:21:17 AM UTC-4, Roberto Rosario wrote:
>>>
>>> The issue has two factors:
>>>
>>> Version 2.2 introduced support for sub-menus and the "Tag" entry in the 
>>> main menu is now a sub menu and no longer a link. The new code to remove 
>>> the entry would be:
>>>
>>> from tags.menus import menu_tags
>>> menu_main.unbind_links(
>>> links=(menu_tags,),
>>> )
>>>
>>> The second issue is that there is no support for unbinding sub-menus. 
>>> Working on adding this now.
>>>
>>> On Wednesday, August 9, 2017 at 12:59:40 AM UTC-4, Roberto Rosario wrote:
>>>>
>>>> There were updates in the link unbinding code:
>>>>
>>>>
>>>> https://gitlab.com/mayan-edms/mayan-edms/commit/e5685eee0418f74070a29f217193289537a5a5c1
>>>>
>>>> https://gitlab.com/mayan-edms/mayan-edms/commit/524a0d0c35041ed8f683a6f0411720e550eafa09
>>>>
>>>> Because it was not working 100% of the case. The updates must have 
>>>> broken the main menu unbinding (when the source is None).
>>>>
>>>> I'm checking the code and adding a test for main menus. Thanks for the 
>>>> report.
>>>>
>>>> On Tuesday, August 8, 2017 at 11:26:51 AM UTC-4, LeVon Smoker wrote:
>>>>>
>>>>> Is the procedure for removing menus from the home page the same as it 
>>>>> used to be? I had been removing the Tags menu, but at some point the code 
>>>>> stopped working. The formerly-working code is:
>>>>>
>>>>> from __future__ import unicode_literals
>>>>>
>>>>> from django.utils.translation import ugettext_lazy as _
>>>>>
>>>>> from common import MayanAppConfig
>>>>>
>>>>> from common import menu_main
>>>>> from folders.links import link_folder_list
>>>>> from tags.links import link_tag_list
>>>>>
>>>>> class HRCSBOverridesApp(MayanAppConfig):
>>>>> name = 'hrcsb_overrides'
>>>>> verbose_name = _('HRCSB Overrides')
>>>>>
>>>>> def ready(self):
>>>>> super(HRCSBOverridesApp, self).ready()
>>>>>
>>>>> # Remove "Tags" links from main menu
>>>>> menu_main.unbind_links(
>>>>> links=(link_tag_list,),
>>>>> )
>>>>> mayan/apps/hrcsb_overrides/apps.py 
>>>>>
>>>>> Thanks,
>>>>> LeVon Smoker
>>>>>
>>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mayan EDMS: 1988] Re: Error while testing a Mailing profile

[Roberto Rosario]

Fix committed 
(https://gitlab.com/mayan-edms/mayan-edms/commit/bb663aa71a83414e216a25639d088668581902bb).
 
Thanks for the report.

On Tuesday, August 8, 2017 at 5:20:58 PM UTC-4, Christian Wiegand wrote:
>
> I have exactly the same Problem. Sending emails works fine, email profile 
> testing fails with the error above
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mayan-edms+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.