[Mayan EDMS: 2283] Mayan EDMS Request for Comment documents (MERCs)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Mayan EDMS: 2283] Mayan EDMS Request for Comment documents (MERCs)

Michael Price
Hi all,

this is the location of the proposed MERCs: https://gitlab.com/Michael.Price/mayan-edms/tree/master/docs/mercs
At the moment we have the following proposals:

* merc-process, MERC-0001 = Process MERC to propose the creation of the MERC documents.
* test-writing, MERC-draft = Process MERC to document and standardize the way tests are written in Mayan EDMS.
* mergin-roles-and-groups, MERC-draft = Feature MERC that proposes the elimination of the Role models and transfer their functionality to the Group model.
* support-forum, MERC-draft = Process MERC that proposes the creation of a support forum for the Mayan EDMS community using a self hosted and proper forum software instead of Google Group, a mailing list platform configured as a forum.

We also created an addendum to the development chapter of the documentation with things that need worked on or fixed. These are things we found during the work done to release version 2.8 of Mayan EDMS NG. The chapter file is here: https://gitlab.com/Michael.Price/mayan-edms/blob/master/docs/topics/development.rst

We believe this proposal procedure and a better documentation process is all that Mayan EDMS needs to continue being a disruptive product in the document management industry.

Copy of the Pending tasks addendum:
--------------

Pending tasks
These are task that need to be completed but are missing a dependency or
a design decision. As more information is added to each, they should be
converted into a MERC.

API

* User API edit view: Should not be able to add of remove groups without
corresponding group access.
* User group list API get & post views: Should adding a group to an user
via the API return 201 or 200. Currently returns 201.
* Consistent API return code for delete views without access. Some views
return 403 other return 404.


Caching

* Size limited caching. A new model in the common app will keep track
of all cache files. A manager method will be provided that will
return the cache files in other of age to be deleted.


Forms processing

* Remove usage of self.cleaned_data. Use self.clean_data instead.


Metadata

* Metadata lookup memory. Add a select2 style widget that will query a
new metadata API endpoint that will return all used values so far.


Notifications

* Fix notification duplication of global & per document subscription
notifications. (This was fixed prior to the release)


Other

* Python based Javascript package manager. Each app specifies what
library and version needs. The common app (or a new app) will add all
the JS loading lines automatically so that compress can detect them.
* When moving documents to the trash update the message to "submitted"
and not "moved" or "deleted" since this is handled by a task queue
and is not immediate and doesn't delete the document.
* When emptying the trash update the message to "submitted"
since this is handled by a task queue and is not immediate.
* New app that allows creating user document filters. Will provide the
same service as the document filters class. Interface can be made
using the template language or the same UI as the smart links.
* Allow add queue metadata that can be exported via a management command.
This will allow creating supervisor templates without all the worker
entries being hardcoded.
* Delete .gitignore files from copied packages. Include .gitignore files
keep compiled or distributable files from being included in the main
repository. Temporary measure until a Javascript library manager is
added.
* Automatically capture license information from installed Javascript
libraries.
* Automatically capture license information from installed Python
packages.


Permissions

* Permission should be reciprocal. Example: To be able to add a tag to a
document, the user must hold the tag add permission for the document
and for the tag to be added. To be able to enable a metadata type to a
document type, the user must hold the metadata add permissions for the
metadata type and for the document type.
* Edit type permissions should only grant the ability to edit the properties
of an object. To modify its relationship with other objects a reciprocal
permission check should be instead.


Sources

* Add ACLs support to sources.
* Provide error message/feedback when scanning from a remote scanner fails.
* Redirect to the same source when scanning from a remote scanner finishes.


Testing

* Add document test mixin that creates documents types and documents
(to be used in dynamic_search.test_api).


UI

* Shift click to select multiple documents.
* During the document upload wizard and the option to double click to
select document type and submit the form. The purpose is to speed up
the step with less mouse travel since this is a common screen.
* Add metadata to the Menu class to allow UI code to decide where and how
to display each menu.


Workflows

* Workflow trigger filters. Example: {{ document.document_type.name = 'invoice' }} or same
UI as the smart links app. Will allow restricting the firing of workflow
actions by a user defined filter criteria.
* Require a permission for document types to avoid a user that has the workflow
creation permission to attach a workflow to a document type they don't
control.
* Research making APIWorkflowDocumentTypeList a subclass of documents.api_views.APIDocumentTypeList
* A POST request to APIWorkflowDocumentTypeList should require some permission
on the document type part to avoid adding non controlled document types
to a new workflow.
* To transition a workflow, the transition permission is only needed for the
workflow. Make it necessary to have the same permission for the document
of document type.
* To view the transition log, the workflow view permission is only needed for the
document. Make it necessary to have the same permission for the workflow or
for the transition and the states.

--

---
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Mayan EDMS: 2302] Mayan EDMS Request for Comment documents (MERCs)

David Kimmel
I just wanted to say that I think this looks great!

I wanted to comment on a couple of proposals:

 Metadata lookup memory. Add a select2 style widget that will query a
new metadata API endpoint that will return all used values so far.

This will be great for data quality and usability.  It may be an idea to put an option on the metadata field to indicate whether this should happen or not on that field.

During the document upload wizard and the option to double click to
select document type and submit the form. The purpose is to speed up
the step with less mouse travel since this is a common screen.

This is one that I think could be fleshed out a bit more.  One of the biggest challenges that I see with Mayan is that it seems to take a lot of clicking to do common tasks.  Double-clicking the document type would be a quick win, but I think there’s a lot more that can be done here.

My ideal upload page would have the Document Type at the top as a dropdown, followed by the metadata fields (this section would refresh when the document type changes), followed by the Tags, and finally the file upload area.  When anything changes all of the areas below get refreshed.  Combined with the first change I quoted, this would make adding documents to Mayan a LOT easier!

I’m not familiar enough with the Mayan codebase to effectively work on these changes, but if it would help I can flesh this out into a draft MERC document.  Thoughts?

Thanks,
-- Dave Kimmel
   [hidden email]



On Feb 28, 2018, at 17:53, [hidden email] wrote:

Hi all,

this is the location of the proposed MERCs: https://gitlab.com/Michael.Price/mayan-edms/tree/master/docs/mercs
At the moment we have the following proposals:

* merc-process, MERC-0001 = Process MERC to propose the creation of the MERC documents.
* test-writing, MERC-draft = Process MERC to document and standardize the way tests are written in Mayan EDMS.
* mergin-roles-and-groups, MERC-draft = Feature MERC that proposes the elimination of the Role models and transfer their functionality to the Group model.
* support-forum, MERC-draft = Process MERC that proposes the creation of a support forum for the Mayan EDMS community using a self hosted and proper forum software instead of Google Group, a mailing list platform configured as a forum.

We also created an addendum to the development chapter of the documentation with things that need worked on or fixed. These are things we found during the work done to release version 2.8 of Mayan EDMS NG. The chapter file is here: https://gitlab.com/Michael.Price/mayan-edms/blob/master/docs/topics/development.rst

We believe this proposal procedure and a better documentation process is all that Mayan EDMS needs to continue being a disruptive product in the document management industry.

Copy of the Pending tasks addendum:
--------------

Pending tasks
These are task that need to be completed but are missing a dependency or
a design decision. As more information is added to each, they should be
converted into a MERC.

API

* User API edit view: Should not be able to add of remove groups without
corresponding group access.
* User group list API get & post views: Should adding a group to an user
via the API return 201 or 200. Currently returns 201.
* Consistent API return code for delete views without access. Some views
return 403 other return 404.


Caching

* Size limited caching. A new model in the common app will keep track
of all cache files. A manager method will be provided that will
return the cache files in other of age to be deleted.


Forms processing

* Remove usage of self.cleaned_data. Use self.clean_data instead.


Metadata

* Metadata lookup memory. Add a select2 style widget that will query a
new metadata API endpoint that will return all used values so far.


Notifications

* Fix notification duplication of global & per document subscription
notifications. (This was fixed prior to the release)


Other

* Python based Javascript package manager. Each app specifies what
library and version needs. The common app (or a new app) will add all
the JS loading lines automatically so that compress can detect them.
* When moving documents to the trash update the message to "submitted"
and not "moved" or "deleted" since this is handled by a task queue
and is not immediate and doesn't delete the document.
* When emptying the trash update the message to "submitted"
since this is handled by a task queue and is not immediate.
* New app that allows creating user document filters. Will provide the
same service as the document filters class. Interface can be made
using the template language or the same UI as the smart links.
* Allow add queue metadata that can be exported via a management command.
This will allow creating supervisor templates without all the worker
entries being hardcoded.
* Delete .gitignore files from copied packages. Include .gitignore files
keep compiled or distributable files from being included in the main
repository. Temporary measure until a Javascript library manager is
added.
* Automatically capture license information from installed Javascript
libraries.
* Automatically capture license information from installed Python
packages.


Permissions

* Permission should be reciprocal. Example: To be able to add a tag to a
document, the user must hold the tag add permission for the document
and for the tag to be added. To be able to enable a metadata type to a
document type, the user must hold the metadata add permissions for the
metadata type and for the document type.
* Edit type permissions should only grant the ability to edit the properties
of an object. To modify its relationship with other objects a reciprocal
permission check should be instead.


Sources

* Add ACLs support to sources.
* Provide error message/feedback when scanning from a remote scanner fails.
* Redirect to the same source when scanning from a remote scanner finishes.


Testing

* Add document test mixin that creates documents types and documents
(to be used in dynamic_search.test_api).


UI

* Shift click to select multiple documents.
* During the document upload wizard and the option to double click to
select document type and submit the form. The purpose is to speed up
the step with less mouse travel since this is a common screen.
* Add metadata to the Menu class to allow UI code to decide where and how
to display each menu.


Workflows

* Workflow trigger filters. Example: {{ document.document_type.name = 'invoice' }} or same
UI as the smart links app. Will allow restricting the firing of workflow
actions by a user defined filter criteria.
* Require a permission for document types to avoid a user that has the workflow
creation permission to attach a workflow to a document type they don't
control.
* Research making APIWorkflowDocumentTypeList a subclass of documents.api_views.APIDocumentTypeList
* A POST request to APIWorkflowDocumentTypeList should require some permission
on the document type part to avoid adding non controlled document types
to a new workflow.
* To transition a workflow, the transition permission is only needed for the
workflow. Make it necessary to have the same permission for the document
of document type.
* To view the transition log, the workflow view permission is only needed for the
document. Make it necessary to have the same permission for the workflow or
for the transition and the states.

--

---
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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Mayan EDMS: 2304] Mayan EDMS Request for Comment documents (MERCs)

Ray Hendricks
Have you been able to work in the issue I brought up last month?

"Mayan-edms tries to insert utf8mb4 into the content column in the document_ocr (i think that is the name) table of the database which was set for utf8.

I converted the database, table, and that column to utf8mb4 and now everything is working."

--

---
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Mayan EDMS: 2306] Mayan EDMS Request for Comment documents (MERCs)

ericriggs42
In reply to this post by David Kimmel
Hi Dave. I'm working on the changes to make Mayan behave like a single page app. Right now every click causes a complete window refresh. This is the "old" way of doing web apps. On one hand it is robust and stands the test of time in term of compatibility on the other hand is slow and only one action can occupy the entire screen at a time. My code makes the main menu static but everything loads via AJAX. This way only the parts than change are refreshed. This also means that assets like jQuery, Bootstrap, FontAwesome, etc, are loaded only once.

I'll make the document uploading more dynamic once the code is stable. You can try out have I have so far by doing a clean git clone and switching to my branch: 

https://gitlab.com/Michael.Price/mayan-edms/commits/feature/single_page_app

Pending tasks that need solving before merging the brach into versions/next:

- Fix API Link URL not resolving. Is set to '#'. Maybe a wrong view name?
- Add hidden to Icon class. The Icon class is missing the hidden-** CSS classes.
- Fix autosubmit form. Triggers OK, but always says "Must select one document". Might have something to do with the querystring.
- Fix Dashboard missing icon. Should be just an update of the icon class from FontAwesome 4 to 5 upgrade.
- Explain javascript code. Write better docstring. And remove console.log statements.
- Implement modal-server-error. Make a modal that pops when an AJAX call fails.
- Fix upload dropzone. The third step of the document upload wizard is not loading its javascript library. Maybe move it to root.html?
- Fix next page link.
- Fix zoom in link. All the document page navigation links are broken. These depend heavily on querystring. Try to support querystrings in the URL hash. URI.js has a plugin for that.
  A better solution would be to store this values as part of the view's URL.
- Fix delete tag cancel button. The {{ previous }} value passed is incorrect. The view is looking at the URL and ignoring the hash. {{ previous }} should now be the hash.
- Set proper "previous" values in views that have a "cancel" or "no" button. A more permanent solution would be to set the {{ prevopus }} values directly instead of relying on the browser's history.

On Sunday, March 4, 2018 at 1:22:34 PM UTC-4, David Kimmel wrote:
I just wanted to say that I think this looks great!

I wanted to comment on a couple of proposals:

 Metadata lookup memory. Add a select2 style widget that will query a
new metadata API endpoint that will return all used values so far.

This will be great for data quality and usability.  It may be an idea to put an option on the metadata field to indicate whether this should happen or not on that field.

During the document upload wizard and the option to double click to
select document type and submit the form. The purpose is to speed up
the step with less mouse travel since this is a common screen.

This is one that I think could be fleshed out a bit more.  One of the biggest challenges that I see with Mayan is that it seems to take a lot of clicking to do common tasks.  Double-clicking the document type would be a quick win, but I think there’s a lot more that can be done here.

My ideal upload page would have the Document Type at the top as a dropdown, followed by the metadata fields (this section would refresh when the document type changes), followed by the Tags, and finally the file upload area.  When anything changes all of the areas below get refreshed.  Combined with the first change I quoted, this would make adding documents to Mayan a LOT easier!

I’m not familiar enough with the Mayan codebase to effectively work on these changes, but if it would help I can flesh this out into a draft MERC document.  Thoughts?

Thanks,
-- Dave Kimmel
   <a href="javascript:" target="_blank" gdf-obfuscated-mailto="9l0E9Kb-DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">davidj...@...



On Feb 28, 2018, at 17:53, <a href="javascript:" target="_blank" gdf-obfuscated-mailto="9l0E9Kb-DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">lonevi...@... wrote:

Hi all,

this is the location of the proposed MERCs: <a href="https://gitlab.com/Michael.Price/mayan-edms/tree/master/docs/mercs" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FMichael.Price%2Fmayan-edms%2Ftree%2Fmaster%2Fdocs%2Fmercs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSWMx9rl-0w3qPm40oWZ59aCYKuQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FMichael.Price%2Fmayan-edms%2Ftree%2Fmaster%2Fdocs%2Fmercs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSWMx9rl-0w3qPm40oWZ59aCYKuQ&#39;;return true;">https://gitlab.com/Michael.Price/mayan-edms/tree/master/docs/mercs
At the moment we have the following proposals:

* merc-process, MERC-0001 = Process MERC to propose the creation of the MERC documents.
* test-writing, MERC-draft = Process MERC to document and standardize the way tests are written in Mayan EDMS.
* mergin-roles-and-groups, MERC-draft = Feature MERC that proposes the elimination of the Role models and transfer their functionality to the Group model.
* support-forum, MERC-draft = Process MERC that proposes the creation of a support forum for the Mayan EDMS community using a self hosted and proper forum software instead of Google Group, a mailing list platform configured as a forum.

We also created an addendum to the development chapter of the documentation with things that need worked on or fixed. These are things we found during the work done to release version 2.8 of Mayan EDMS NG. The chapter file is here: <a href="https://gitlab.com/Michael.Price/mayan-edms/blob/master/docs/topics/development.rst" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FMichael.Price%2Fmayan-edms%2Fblob%2Fmaster%2Fdocs%2Ftopics%2Fdevelopment.rst\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFT2j4BytviuLZQz1bnKucW1BouwA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2FMichael.Price%2Fmayan-edms%2Fblob%2Fmaster%2Fdocs%2Ftopics%2Fdevelopment.rst\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFT2j4BytviuLZQz1bnKucW1BouwA&#39;;return true;">https://gitlab.com/Michael.Price/mayan-edms/blob/master/docs/topics/development.rst

We believe this proposal procedure and a better documentation process is all that Mayan EDMS needs to continue being a disruptive product in the document management industry.

Copy of the Pending tasks addendum:
--------------

Pending tasks
These are task that need to be completed but are missing a dependency or
a design decision. As more information is added to each, they should be
converted into a MERC.

API

* User API edit view: Should not be able to add of remove groups without
corresponding group access.
* User group list API get & post views: Should adding a group to an user
via the API return 201 or 200. Currently returns 201.
* Consistent API return code for delete views without access. Some views
return 403 other return 404.


Caching

* Size limited caching. A new model in the common app will keep track
of all cache files. A manager method will be provided that will
return the cache files in other of age to be deleted.


Forms processing

* Remove usage of self.cleaned_data. Use self.clean_data instead.


Metadata

* Metadata lookup memory. Add a select2 style widget that will query a
new metadata API endpoint that will return all used values so far.


Notifications

* Fix notification duplication of global & per document subscription
notifications. (This was fixed prior to the release)


Other

* Python based Javascript package manager. Each app specifies what
library and version needs. The common app (or a new app) will add all
the JS loading lines automatically so that compress can detect them.
* When moving documents to the trash update the message to "submitted"
and not "moved" or "deleted" since this is handled by a task queue
and is not immediate and doesn't delete the document.
* When emptying the trash update the message to "submitted"
since this is handled by a task queue and is not immediate.
* New app that allows creating user document filters. Will provide the
same service as the document filters class. Interface can be made
using the template language or the same UI as the smart links.
* Allow add queue metadata that can be exported via a management command.
This will allow creating supervisor templates without all the worker
entries being hardcoded.
* Delete .gitignore files from copied packages. Include .gitignore files
keep compiled or distributable files from being included in the main
repository. Temporary measure until a Javascript library manager is
added.
* Automatically capture license information from installed Javascript
libraries.
* Automatically capture license information from installed Python
packages.


Permissions

* Permission should be reciprocal. Example: To be able to add a tag to a
document, the user must hold the tag add permission for the document
and for the tag to be added. To be able to enable a metadata type to a
document type, the user must hold the metadata add permissions for the
metadata type and for the document type.
* Edit type permissions should only grant the ability to edit the properties
of an object. To modify its relationship with other objects a reciprocal
permission check should be instead.


Sources

* Add ACLs support to sources.
* Provide error message/feedback when scanning from a remote scanner fails.
* Redirect to the same source when scanning from a remote scanner finishes.


Testing

* Add document test mixin that creates documents types and documents
(to be used in dynamic_search.test_api).


UI

* Shift click to select multiple documents.
* During the document upload wizard and the option to double click to
select document type and submit the form. The purpose is to speed up
the step with less mouse travel since this is a common screen.
* Add metadata to the Menu class to allow UI code to decide where and how
to display each menu.


Workflows

* Workflow trigger filters. Example: {{ <a href="http://document.document_type.name" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocument.document_type.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGPiIcWGI0zQVgUnLdjRy2FF9_ZkA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocument.document_type.name\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGPiIcWGI0zQVgUnLdjRy2FF9_ZkA&#39;;return true;">document.document_type.name = 'invoice' }} or same
UI as the smart links app. Will allow restricting the firing of workflow
actions by a user defined filter criteria.
* Require a permission for document types to avoid a user that has the workflow
creation permission to attach a workflow to a document type they don't
control.
* Research making APIWorkflowDocumentTypeList a subclass of documents.api_views.APIDocumentTypeList
* A POST request to APIWorkflowDocumentTypeList should require some permission
on the document type part to avoid adding non controlled document types
to a new workflow.
* To transition a workflow, the transition permission is only needed for the
workflow. Make it necessary to have the same permission for the document
of document type.
* To view the transition log, the workflow view permission is only needed for the
document. Make it necessary to have the same permission for the workflow or
for the transition and the states.

--

---
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="9l0E9Kb-DAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mayan-edms+...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
For more options, visit https://groups.google.com/d/optout.