Project

General

Profile

Bug #3390

wiki problems

Added by dominique de guchtenaere over 8 years ago. Updated about 7 years ago.

Status:
Feature implemented
Priority:
Normal
Assignee:
-
Start date:
10/05/2011
Due date:
% Done:

0%

Estimated time:
Complexity:
Normal

Description

1. the owner of a wiki page (in a wiki in a course) cannot edit his own page from the course-wiki (he gets a blank page). He can edit it in his repository, but when he clicks the button "update", a new version is created, which isn't published in the course wiki.
2. other users wanting to edit a wiki page, can't access the edit function because they are getting a blank screen.
3. a student cannot view the history of his own wiki page.
4. a course manager can edit a wiki page in a course wiki, but the changes are stored under the name of the owner of the page. So it isn't possible to see who made the changes.


Files

patches_voor_wiki.zip (7.07 KB) patches_voor_wiki.zip temporary fix to make wiki-tool usable Nathalie Blocry, 16/08/2011 12:24

History

#1

Updated by Stefaan Vanbillemont over 8 years ago

  • Target version set to 2.1.0
#2

Updated by Nathalie Blocry about 8 years ago

this is the same issue as Bug #2924

there are some problems creating these bugs

1) the is_allowed in the components always returns false because it checks for an unknown right in an unknown context
e.g. $this->is_allowed(EDIT_RIGHT). I think this is something that has never been refactored when the right-system has been refactored. so to start the "EDIT_RIGHT" or "VIEW_RIGHT" should be subsituted by a number representing an actual right (but in which context? --> see 2)

2) there is again an inconsistency between publication-right and repository rights. the is_allowed() that is actually performed is the one from the CourseViewer but if we want the rights that are set in the course-context to exclusively handle the rights for the publication, not the actual content object in the publication, the "is_allowed" should be performed by the repository.
I personally don't agree with that: if I give edit-right on a wiki to someone in a course I expect them to be able to actually edit the content of the wiki, but this is an issue that has been raised already several times. the inconsistency that is already present is this: the "add-right" that you can set on the publication does already allow you to add pages to the wiki, which is very logical if you use common sense, but not logical if you use the chamilo-philosophy. So the ADD-right is set for the content-object, not for the publication.

the first 3 points are all results of the same problem. the 4th point is unrelated to these rights-problems so I think this should be a separate ticket.(Bug #3794)

#3

Updated by Nathalie Blocry about 8 years ago

I think this should also be moved to the weblcms project as the behavior might be different in the wiki application

#4

Updated by Nathalie Blocry about 8 years ago

we have looked for a short-term solution and "fixed" this on our test-installation so the wiki-tool can be used and tested for usability during our pilot.
we have not fixed it using the share/repository rights but using the publication-rights in the weblcms. In all other contexes, the behavior stays as is (= broken?).
So in our case the view/edit/add-rights that are checked are those set on the publication.

we are not using share/repository rights during our pilot as we find the system overly complicated for the users.
to really fix this in the chamilo-way some bigger refactoring (and re-thinking) needs to be done.

#5

Updated by Stefaan Vanbillemont over 7 years ago

  • Target version changed from 2.1.0 to Backlog (default)
#6

Updated by Anthony Hurst about 7 years ago

  • Status changed from New to Feature implemented

Will be fixed in a future release with the planned reworking of the rights systems.

Also available in: Atom PDF