-
Notifications
You must be signed in to change notification settings - Fork 9
elisctl usecases
Developers working with Elis are generally taking care of three tasks:
- Configuration: Elis setup per user's requirements (first priority)
- Integration: Getting data from outside systems to Elis and from Elis to outside systems
- Customization: Customizing Elis to support the specific user (business rules, interactivity, workflow)
Typical situation for initial Elis users ("BASIC" scenario): Single organization, workspace, queue, a dedicated schema and an admin user. elisctl should make working in the BASIC scenario easy, and working in the more complex scenarios possible. Best interfaces are discoverable - i.e. what you learned as BASIC users should be reusable in the complex scenario again.
(...often add many new users at once.)
List ideally with workspace-based filter being only optional.
In the BASIC scenario, likely iterating a bit by trial and error before finding the ideal schema.
In more advanced scenarios, I think it's fine to assume and enforce that each queue would have a separate schema object (that could make the interface much more straightforward to do).
This includes the awesome xls-to-enum tooling.
Likely with a filter, hypothesis is that users will (almost?) always filter at least by status.
Either for the whole queue or for a single document.
This includes the CSV transformation tooling.
("Move" may mean "copy & delete" or some-such.)