I have a question about fiware-skuld.
Is It working Skuld within a federation?
Must be use globally or in each FIWARE Lab region?
It is not a good idea to run individually Skuld on each region. There are some
serious problems:
the users are global. The change of the user type (from Trial Users to Basic Users type) can be invoked only one time. The same is true for the notifications. Users do not want a
notification for each region.
there is a problem of synchronisation if each region delete their
resources when they want. Users must be notified only one time and
with a defined anticipation.
At this moment the scripts are invoked only for a region, but to support a
federation it is sufficient to modify only the scripts that delete resources to
iterate with each region.
I'm trying to retrieve the number of edits made by bots, registered users and anonymous users separated for a specific wikipedia article.
I know I can get all revisions for an article by the revision prop in the MediaWiki API, I was thinking to use rvprop=user to return the name of the user who made the revision and do some processing on the retrieved data.
http://ar.wikipedia.org/w/api.php?action=query&prop=revisions&titles=%D8%A7%D8%A8%D9%86%20%D8%A7%D9%84%D9%86%D9%81%D9%8A%D8%B3&rvlimit=500&rvprop=timestamp%7Cuser|size&format=xml
for anonymous users revisions the anon="" occurs always so I can count it, but for the bots I can't find a way, as far as I know the bots names are not always written in a standardized way.
Any idea how to do it? or an easier way maybe using another API to do this task?
The revisions API lets you list the flags for each revision - they include whether an edit was marked as a minor or bot edit. For example, see these revisions.
However, it looks like the edits in your linked data set were made without flagging them as bot edits, either because those bots are not approved bots or because they forgot to set the flag. In that case, you're quite out of luck. You still can filter against the term bot in the username or the known list of bots in your wiki.
I moderate a wiki where many users use the AutoWikiBrowser to rapidly edit. This is fine but it makes it harder to locate and deal with vandalism via the recent changes. Is there any way that I can create a custom edit flag to mark edits as semi-automated and allow users to hide them from the recent changes? Ideally this would come with the ability to mark edits as semi-automated by default, which would allow the functionality I seek without needing a change to the AWB source code.
The ability to mark one's edits as semi-automated shouldn't be open to anyone, so it would need to be restricted to certain usergroups (probably rollback and up). I realise that there is the ability to mark edits as bot edits, but this is inaccurate as they are not truly bots, and inconvenient, since it requires a bureaucrat to mark the user as a bot, then unmark them when their editing is finished. I realise its a lot to request, and I certainly understand if its not possible, but I was hoping that it was.
Why not have users use two accounts - one for manual edits and one for bot edits? Or is that too much overhead for the users?
As you say, if your bots have their own accounts you can add them to the bot group. Then users can, in Recent Changes, decide themselves to show / hide bot edits.
Then your admins can patrol the changes as usual.
The solution is very simple: add a user group whose users are able to add and remove themselves (via Special:userrights) to the default "bot" group or to another group "flood" having only the "bot" and perhaps "noratelimit" permission; then add those users to this group.
On a wiki-style website, what can I do to prevent or mitigate write-write conflicts while still allowing the site to run quickly and keeping the site easy to use?
The problem I foresee is this:
User A begins editing a file
User B begins editing the file
User A finishes editing the file
User B finishes editing the file, accidentally overwriting all of User A's edits
Here were some approaches I came up with:
Have some sort of check-out / check-in / locking system (although I don't know how to prevent people from keeping a file checked out "too long", and I don't want users to be frustrated by not being allowed to make an edit)
Have some sort of diff system that shows an other changes made when a user commits their changes and allows some sort of merge (but I'm worried this will hard to create and would make the site "too hard" to use)
Notify users of concurrent edits while they are making their changes (some sort of AJAX?)
Any other ways to go at this? Any examples of sites that implement this well?
Remember the version number (or ID) of the last change. Then read the entry before writing it and compare if this version is still the same.
In case of a conflict inform the user who was trying to write the entry which was changed in the meantime. Support him with a diff.
Most wikis do it this way. MediaWiki, Usemod, etc.
Three-way merging: The first thing to point out is that most concurrent edits, particularly on longer documents, are to different sections of the text. As a result, by noting which revision Users A and B acquired, we can do a three-way merge, as detailed by Bill Ritcher of Guiffy Software. A three-way merge can identify where the edits have been made from the original, and unless they clash it can silently merge both edits into a new article. Ideally, at this point carry out the merge and show User B the new document so that she can choose to further revise it.
Collision resolution:
This leaves you with the scenario when both editors have edited the same section. In this case, merge everything else and offer the text of the three versions to User B - that is, include the original - with either User A's version in the textbox or User B's. That choice depends on whether you think the default should be to accept the latest (the user just clicks Save to retain their version) or force the editor to edit twice to get their changes in (they have to re-apply their changes to editor A's version of the section).
Using three-way merging like this avoids lock-outs, which are very difficult to handle well on the web (how long do you let them have the lock?), and the aggravating 'you might want to look again' scenario, which only works well for forum-style responses. It also retains the post-respond style of the web.
If you want to Ajax it up a bit, dynamically 3-way merge User A's version into User B's version while they are editing it, and notify them. Now that would be impressive.
In Mediawiki, the server accepts the first change, and then when the second edit is saved a conflicts page comes up, and then the second person merges the two changes together. See Wikipedia: Help:Edit Conflicts
Using a locking mechanism will probably be the easiest to implement. Each article could have a lock field associated with it and a lock time. If the lock time exceeded some set value you'd consider the lock to be invalid and remove it when checking out the article for edit. You could also keep track of open locks and remove them on session close. You'd also need to implement some concurrency control in the database (autogenerated timestamps, perhaps) so that you could make sure that you are checking in an update to the version that you checked out, just in case two people were able to edit the article at the same time. Only the one with the correct version would be able successfully check in an edit.
You might also be able to find a difference engine that you could just use to construct differences, though displaying them in a wiki editor may be problematic -- actually displaying the differences is probably harder than constructing the diff. You'd rely on the versioning system to detect when you needed to reject an edit and perform a diff.
In Gmail, if we are writing a reply to a mail and someone else sends a reply while we are still typing it, a popup appears indicating that there is a new update and the update itself appears as another post without a page reload. This approach would suit your needs and if you can use Ajax to show the exact post with a link to diff of what was just updated while User B is still busy typing his entry that would be great.
As Ravi (and others) have said, you could use an AJAX approach and inform the user when another change is in progress. When an edit is submitted, just indicate the textual differences and let the second user work out how to merge the two versions.
However, I'd like to add on with something new you could try in addition to that: Open a chat dialog between the editors while they're doing their edits. You could use something like embedded Gabbly for that, for instance.
The best conflict resolution is direct dialog, I say.
Your problem (lost update) is solved best using Optimistic Concurrency Control.
One implementation is to add a version column in each editable entity of the system. On user edit you load the row and display the html form on the user. A hidden field gives the version, let's say 3. The update query needs to look something like:
update articles set ..., version=4 where id=14 and version=3;
If rows returned is 0 then someone has already updated article 14. All you need to do then is how to deal with the situation. Some common solutions:
last commit wins
first commit wins
merge conflicting updates
let the user decide
Instead of an incrementing version int/long you can use a timestamp but it's not suggested because:
retrieving the current time from the JVM isn't necessarily safe in a clustered environment, where nodes may not be time synchronized.
(quote from Java Persistence with Hibernate)
Some more info at the hibernate documentation.
At my office, we have a policy that all data tables contain 4 fields:
CreatedBy
CreatedDate
LastUpdateBy
LastUpdateDate
That way there is a nice audit trail on who has done what to the records, at least most recently.
But most importantly, it becomes easy enough to compare the LastUpdateDate of the current or edited record on the screen (requires you to store it on the page, in a cookie, whatever, with the value in the database. If the values don't match, you can decide what to do from there.
Is it possible & if so, how can I allow users to only create a certain number of pages. ie. When they sign up, only allow them to create one page?
Off the top of my head, the following approach ought to work:
Hook into the userCan event for the "edit" action, check the page's existence (i.e. $title->exists()) and if it doesn't, consult some stored count (see below), and if the decision reached is to disallow creation, set $result to false and return false to stop further hooks overriding the decision.
Hook into the ArticleInsertComplete event and update some stored count to reflect that the user ($user) has created another page.
The decision in #1 can be expanded via additional logic to support multiple policies in conjunction with, e.g. automatic rights assignment; for example, to allow users to create more than one page after they've reached so-called "auto-confirmed" status, or to ignore the check for administrators or other users with specific rights.
I don't know what exactly you want to do, but I bet you want to let them make only user page or something? It might be simpler for you to just restrict their editing to a certain namespace, until they are added to some special group.
Some more info might help us answer the questions better. Do you also want to restrict their editing to the page they create?