mirror of
https://github.com/TheAnachronism/docspell.git
synced 2025-06-20 17:39:54 +00:00
Website tweaks
This commit is contained in:
@ -56,20 +56,21 @@ application is a
|
||||
in [Elm](https://elm-lang.org) and is a client to the REST api. All
|
||||
features are available via a http/rest api.
|
||||
|
||||
The *joex* is the component that does the “heavy work”, excuting
|
||||
The *joex* is the component that does the “heavy work”, executing
|
||||
long-running tasks, like processing files or importing your mails
|
||||
periodically. While the joex component also exposes a small REST api
|
||||
for controlling it, the user interface is all inside the rest server
|
||||
api.
|
||||
for controlling it, the main user interface is all inside the rest
|
||||
server api.
|
||||
|
||||
The rest server and the job executor can be started multiple times in
|
||||
order to scale out. It must be ensured, that all connect to the same
|
||||
database.
|
||||
database. And it is also recommended (though not strictly required),
|
||||
that all components can reach each other.
|
||||
|
||||
The fulltext search index is another separate component, where
|
||||
currently only SOLR is supported. SOLR also supports running in a
|
||||
distributed way. Fulltext search is optional, so the SOLR component is
|
||||
not required if docspell is run without fulltext search support.
|
||||
currently only [SOLR](https://lucene.apache.org/solr) is supported.
|
||||
Fulltext search is optional, so the SOLR component is not required if
|
||||
docspell is run without fulltext search support.
|
||||
|
||||
|
||||
# Terms
|
||||
@ -79,39 +80,39 @@ explained.
|
||||
|
||||
## Item
|
||||
|
||||
An *Item* is roughly your document, only that an item may span
|
||||
multiple files, which are called **attachments**. An item has **meta
|
||||
data** associated:
|
||||
An *item* is roughly your document, only that an item may span
|
||||
multiple files, which are called *attachments*. An item has *meta
|
||||
data* associated:
|
||||
|
||||
- a **correspondent**: the other side of the communication. It can be
|
||||
- a *correspondent*: the other side of the communication. It can be
|
||||
an organization or a person.
|
||||
- a **concerning person** or **equipment**: a person or thing that
|
||||
- a *concerning person* or *equipment*: a person or thing that
|
||||
this item is about. Maybe it is an insurance contract about your
|
||||
car.
|
||||
- **tag**: an item can be tagged with one or more tags (or labels). A
|
||||
- *tag*: an item can be tagged with one or more tags (or labels). A
|
||||
tag can have a *category*. This is intended for grouping tags, for
|
||||
example a category `doctype` could be used to group tags like
|
||||
`bill`, `contract`, `receipt` etc. Usually an item is not tagged
|
||||
with more than one tag of a category.
|
||||
- a **folder**: a folder is similiar to a tag, but an item can only be
|
||||
- a *folder*: a folder is similiar to a tag, but an item can only be
|
||||
in exactly one folder (or none). Furhtermore folders allow to
|
||||
associate users, so that items are only visible to the users who are
|
||||
members of a folder.
|
||||
- an **item date**: this is the date of the document – if this is not
|
||||
- an *item date*: this is the date of the document – if this is not
|
||||
set, the created date of the item is used.
|
||||
- a **due date**: an optional date indicating that something has to be
|
||||
- a *due date*: an optional date indicating that something has to be
|
||||
done (e.g. paying a bill, submitting it) about this item until this
|
||||
date
|
||||
- a **direction**: one of "incoming" or "outgoing"
|
||||
- a **name**: some item name, defaults to the file name of the
|
||||
- a *direction*: one of "incoming" or "outgoing"
|
||||
- a *name*: some item name, defaults to the file name of the
|
||||
attachments
|
||||
- some **notes**: arbitrary descriptive text. You can use markdown
|
||||
- some *notes*: arbitrary descriptive text. You can use markdown
|
||||
here, which is properly formatted in the web application.
|
||||
|
||||
## Collective
|
||||
|
||||
The users of the application are part of a **collective**. A
|
||||
**collective** is a group of users that share access to the same
|
||||
The users of the application are part of a *collective*. A
|
||||
*collective* is a group of users that share access to the same
|
||||
items. The account name is therefore comprised of a *collective name*
|
||||
and a *user name*.
|
||||
|
||||
|
Reference in New Issue
Block a user