PROPOSALS
A proposal represents a political project. It is necessarily classified in a theme.
It contains a general motive and some articles that are written by the author. The general motive gives the general idea of the project. It should be understandable by anyone. The articles are supposed to give the details of the project in juridical terms, as a legal text. Each article is also motivated.
Some public discussions about the all proposal - or a particular article - can be opened by any logged user.
Starting from the first publication, a proposal is versioned. Each modification is saved. Anyone can view the history of a proposal.
The proposals are implemented with the Proposal class. Its main arguments are:
- $title : not unique. Different proposals can have the same title, but the slug is unique.
- $abstract : a short description of 400 characters maximum
- $motivation : a complete description of the motives
- $articles : a proposal, as a standard law, is composed of articles, which are implemented by the Article class.
- $versionNumber
- ?? $isAWiki : if the proposal is a wiki, every user can edit it. We will probably remove this behavior since we would like the author to be the moderator of the proposal. If there is no moderator anymore this task would go to the general moderation which would be to much work
- $theme : the theme it is classified in
- $author : the author of the proposal and its administrator
- $supporters : the users that support the proposal
- $opponents : the users that claim to be opposed to the proposal
- $versioning : an array of the versions of the proposal (ProposalVersion entity) since its first publication. Each time the author modifies the proposal, a new ProposalVersion is created. A ProposalVersion entity represents a snapshot of the proposal at a given time
- $discussions : the public discussions associated to the proposal
Any logged user can create a proposal through a theme view. The proposal will then be classified in this theme and publicly visible. The user becomes the author of the proposal.
There are two main ways to modify a proposal : the edition and the addition or the modification of an article.
Every time a modification is done, a snapshot of the proposal is done (a ProposalVersion object is created) to maintain the versioning.
By editing a proposal the user can modify the title, the abstract and the general motives of the proposal.
?? The edition of a proposal can be done by the author, by the general administrator, or by any logged user if the proposal is a wiki. We will probably remove the last two possibilities. The general administrator should not have the right to edit the proposal, but should be able to moderate it (prevent its activity for a while, or move it from the tree, or hide it from public view in the worst case). Those autorizations are implemented by the ProposalVoter class (edit right).
The user can also add an article. It will create an Article entity.
Each article has its own space. Some discussions can be associated to it. It has its own versioning.
Each time an article is modify, the versioning of the article is updated (an ArticleVersion entity is created), but also the versioning of the proposal (a ProposalVersion entity is created).
Every logged user can support or contest a publish proposal. He can then access the proposal from his profile.
The numbers of supporters/opponents should not be made public to prevent any snowball effect.
This functionality will probably be usefull in the next versions of the application when it will be possible to simulate some votes.
Any logged user can create a public discussion in the forum of the proposal.
The general administrator can move a proposal to another theme.
Only the general administrator can suppress a proposal from the database. The suppression of a proposal will cascade the suppression of the versioning of the proposal, the discussions, the articles, the versioning of the articles, the discussions of the articles.
?? Should the author be allowed to remove his proposal ?