|
Introduction
IntroductionWe currently have a reference implementation for the backend in the backend-prototype branch that will not be developed further. Based on this reference implementation we are now in the process of implementing the a final version of the backend and frontend. During planning we had to address the fact that we weren't sure how many development resources we have available. So we created plan A and plan B in order to be able to provide a fully working solution either way:
The following specification just details the functional delta between the current backend prototype and the final planned version. All features which are required for plan B will be noted as such. Due to resource constraints we ended up going with Plan B. General requirementsIt needs to be possible to define what admintools are accessible to what user groups. Further certain actions within admin tools also need to be restrict-able (For example setting a Document to status active should be limited to certain users). Ideally there would be a versioned history of all entities. Ideally there would also be some support tools/filters to aid the editorial process like being able to see a list of items that need review, seeing all items which were created/modified by someone specific etc. Frontend SpecificationsSearch similar to kayak.com (aka some basic search forms lead to a search result with checkboxes and sliders to further tweak the result set) The pages for clauses and documents should heavily interlink to show the relations between them Users should be able to register Logged in users should be able to bookmark and comment clause and documents Backend Specifications
|
Is there any overlap, lessons learned or plain reuse from: http://www.undemocracy.com/ http://webapps01.un.org/mandatereview/searchStart.do or http://www.uncorpora.org/
Would be a shame to completely reinvent the wheel! Innovate on shoulders of others, etc.