By mistake I commandeered a revision in phabricator.
Can I undo this, or does the original owner have to commandeer it back?
I tried abandoning the revision but that doesn't remove me as owner, just marks it abandoned.
The owner is not displayed or editable in the edit revision page
This is not possible.
You would need the original author to commandeer it back.
Related
Yesterday updated the new version of wordpress to some sites that I maintain. But in all the following problem: When creating a new post and click the publish button, nothing is published, it is always as a draft, the process of publishing does not end.
(Not an answer, I can't comment yet cause I don't have enough points.)
I am seeing the same issue.
"Quick Edit" in the Posts lists works, but Editing the post does not.
Some odd behaviours:
Update & Publish fail by a) not saving any of the Post's information or settings to the database and b) pushing the user out to the All Posts List
Version Control notification that what is currently in the text box is not the same as what is cached. Regardless if I Undo or not, Update & Publish both fail.
Editing old posts and creating new posts, same problem.
Bewilderingly, sometimes it goes through. But so randomly I have yet to figure out why.
My guess is there is some conflict between the version checking, auto-save and perhaps content checker (html?).
Sorry I can't be of more help. Hope someone figures this out... Posting posts is the one thing I expect Wordpress to do. It has one job, so to speak. ;)
I want to add the logs for the requirement history for the changes in the requirement tracebility. Currently,the logs for the changes in the requirement tracebilyt are not being captured in the history section.
Is any code or API to make changes in the requirement tracebility visible in the history tab?
thanks
History is not maintained for requirement traceability in QC. What you can do, enable history for comment field from customization and change your qc workflow script such that it adds comment (i.e. added link/removed link with ids) when somebody changes anything in requirement traceability section.
you have to make the Related field history enabled and to do so, you have to have administration rights on the project.
then go to Tools>Customization>Project Entities> Test Cases
then find your field in either the System Fields list or the User Fields list.
select the target field, in the RHS you will see the field properties and one of the properties is History Enabled. check that option and Save then Hit Return.
Log out of the project and re-Login.
now changes to that field will be tracked and appear in the History tab.
In Sitefinity, almost everything is able to be revisioned. In the backend interface at a page for a content item you can click on Revision History and see revisions.
We're in a situation where we're manually uploading documents in to the Documents & Files library through a custom form. We're able to do this using the Content Lifecycle which has pretty good documentation: http://www.sitefinity.com/documentation/gettingstarted/developers-guide/sitefinity-essentials/modules/content-lifecycle .
What doesn't have any documentation is how to modify a document so that it updates the revision of that document programmatically, not replace it. Right now, we're only able to replace it and the revision history stays empty.
I think you cannot keep the previous version of the document in Sitefinity.
The revision history for the documents keeps track for the metadata only, e.g. Title, Author, etc.
If you replace the file, there is no way to revert it back through the Revision History.
Disclaimer: I haven't tested this in the 7+ versions.
When I make a substantial update (not just correcting a typo) to an article in my blog, I want to ensure that readers see the updated article again in their news feed. From what I have read, here are some of the options I see:
Create an entirely new article (largely a duplicate of the original). Apparently a bad idea -- duplicate content would be bad for SEO.
Change the published and/or updated timestamp of the article. It seems that, in most readers, this will not make the article show up as unread.
Change the RSS item GUID or Atom entry id. This is a big NO-NO according to the Atom specs, but I'm not sure about RSS.
So, there doesn't seem to be a good option, unless I'm missing something.
What are the ramifications of changing RSS item GUID or Atom entry id? Are the Feed Police going to show up at my door for changing an article ID?
updating the "updated" field for that entry should be correct. Do not forget to also update "updated" field for feed itself, any Etags/last-modified HTTP headers (if existing but not auto-generated), and wait/force reader to actually do the refresh.
if you still have the problems with some of the readers you should check with feed reading software authors to see if that is intentional.
As for the second part, changing id won't get Feed Police on your door, but if it happens often enough, such articles which would show as duplicate could annoy your followers to just ignore/drop the feed.
see this and this answers too
The RSS <guid> or Atom <id> is an element used to uniquely identify its parent item. Feed readers and aggregators use this field to determine if the item has already been downloaded or fetched.
If you change an RSS <guid> or Atom <id>, then readers and aggregators may use this as a signal or flag that the item is to be downloaded again because the GUID or ID held previously no longer matches what it has in its database or lookup.
Changing the GUID or ID is not a way to force an update in place. It's a way to say, "I have something brand new for you to download/fetch".
In RSS, if you add ?fake=parameter to the GUID that can be a substitute way to force a new download. But the old fetched item will still remain because it doesn't share the GUID.
You can't reliably force a download via RSS or Atom using the publish or updated date.
Best you can do is to change the contents of the item and allow readers or aggregators to update as they wish, as not all work the same in what they do when they see a change in content like this for an item it already has.
As both answers at this point state: there is no perfect way. Changing the guid will make everyone believe that the content is brand new, hence probably creating duplicate content, and chaging just the element will probably not always trigger a full refresh.
Using PubSubHubbub may help as it is fat pings. Wich means that the subscriber will get the updated data right away and can store it under the same key/unique id that the previous version.
I have come across this problem in the past but never solved it.
I am on the verge of finishing a Drupal site for a client. I created two content types and gave him the permissions necessary to edit any occurrence of these node types.
The strange problem is the client can edit any node of type product_type except for one particular node of the same type.
So in other words, all nodes of type product_type are editable except node/3.
Do you have a node access module installed, like Content Access or Taxonomy Access Control? If you do, it could be that there are per-node permissions set and your client's role doesn't have permission to edit that node, or it could be that it is tagged with a particular taxonomy term which prevents him from editing it.
If you don't have any extra node access modules installed, is it just that the link to "Edit" is missing in the tabs section of the page? Can the client type in "http://example.com/node/3/edit" and reach the edit screen that way?
If you supply an answer to these questions in the comments, I'll edit this answer as best I can.
Check the author of the node. If it's different than the client's user account that may account for the problem. If that does not work you may need to "rebuild permissions."
I found out what the issue was. The client account could not edit anything with full-html input format.
I enabled that at /admin/settings/filters and it works just fine now.
Thanks for looking in.