Sometime someone want to change inside something crx directly on environment.
Often it is a cause of unworking state of environment. And often enough hard to find the cause of the problem. And I think it is will be helpful if cq5 crx will have audit log. something like this.
12.12.12 21:03 /etc/blueprints/geometrixx was removed [rollout]
...
maybe CQ5 has something like this already?
Assuming these changes to the repositories are made using crxde lite[/crx/de/index.jsp] or content explorer [/crx/explorer/browser/index.jsp] , there is an indirect way to find out who did it.
The data can be fetched by looking into two different logs request.log and audit.log [these files can be found at \crx-quickstart\logs folder ]
The modifications to nodes are POST requests. These are logged in request.log , the path of the request will only show the interface used or to root node. If you search the time stamp of the POST in audit.log you can find which user did a GET request.
This is not direct way, nor will it tell more of the changes except for which user read the node at the time of the POST .
Related
I'd like to configure the Adobe Cloud Manager production pipeline to invalidate the whole dispatcher cache. What paths do I have to give at the production pipeline dispatcher invalidation configuration to have that done? Is it possible to give a pattern here that matches everything? The page-invalidate description talks about a path-pattern, but doesn't describe what exactly that means.
We work with statfilelevel=2. It seems the .stat files are very important for that, though the description given here is unfortunately not precise enough, not sure I understand that right.
I tried to configure /content as path - that just touches /mnt/var/www/html/.stat (/mnt/var/www/html is the docroot), which seems to apply to nodes like /* but not like /content/* .
If I give /content/oursite, that touches /mnt/var/www/html/content/.stat , too, but that does seem to apply to nodes like /content/oursite or /content/othersite, but not to pages like /content/oursite/about - for which would /mnt/var/www/html/content/oursite/.stat be relevant, if I understand that right.
Do I seriously have to enumerate a page in each site that has a .stat file, or is there a more sensible way to get everything invalidated? After all, a deployment could easily change the HTML of every page if a component has changed.
If you have ACS commons installed then you can try to use this powerful feature
https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-rules/index.html
I have added a 'number_of_members' value to the Customer DocType via customization.
In my application I have tried several ways to update the value. However the value never updates in the webpage. I feel like I'm missing some sort of save or update or commit step.
For example I have tried:
frappe.client.set_value('Customer', '00042', 'number_of_members', 8887)
frappe.set_value('Customer', '00042', 'number_of_members', 8887)
frappe.db.set_value('Customer', '00042', 'number_of_members', 8887)
and also
customer = frappe.get_doc('Customer', '00042')
customer.number_of_members = 8887
customer.save()
In each case I can do something like frappe.get_value, or frappe.get_doc and it shows the value is set to 8887. However it never updates in the web side. This is what makes me think I'm updating some sort of cache or database transaction and I need some way to save it, but have not had any luck.
I am mostly testing this via bench console if that has any bearing on it, but I've tried a couple of the methods in my application code as well.
Relevant documentation:
Frappe Developer API - Document
Frappe Developer API - Database
Turns out the answer is to call frappe.db.commit() after making changes. If someone can point this out in the documentation so I can better understand how I'm missing stuff, I would appreciate it.
I also noticed if you try to Save something in the UI before you send frappe.db.commit() the UI will hang.
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
This is the scenario (CQ5.6). Let's say there is the following node /content/geometrixx/articles, with articles inside of it. In author instance I create a package as a backup of that node. Then I deactivate article1 inside of articles, if I try to access the page I get a 404 page, that is fine. However if I build the backup package again and then replicate it, the deactivated page (article1) is available, that is, I do not get the 404 but instead the article.
Is there a way to replicate a package while preserving deactivated pages? That is, how I avoid re-activation?
Replicating package means that you are replicating every thing available in Package. Which means publish environment will have deactivated pages also. There are several ways to handle it, like:
Simplest way is to add a check in template (as first rule) to see if Env==publish && requested resource ==not activated, if so, return 404 page.
Another way is to create a script to delete all deactivated pages, and run this script on publish after page activation.
Add exclude filters in your package to exclude such pages.
I would recommend to use #1 as this is one time change and will be future proof.
should use treeactivation: http://localhost:4502/etc/replication/treeactivation.html, much safer (since you have 3 options: Only Modified, Only Activated and Ignore Deactivated)
We are in the proces of adding our data import functionality to our RESTful interface.
We are trying to come up with a RESTful way to handle this proces.
From a user perspective we have the following proces:
(1) The user uploads a file (2) the user selects some configuration options that control how the data is entered into the system and the system presents a preview of the result (the user can change the settings untill satisfied) (3) once the user confirms everything is correct the import is executed. This results in new elements being created in the /participants resource.
Currently we upload the data to a /imports resource on step 1. Everytime the user changes the import configuration we save the new configuration to the resource and get back a new preview. We have a differenco of opinion about what the "go ahead and process the input" action should look like and whether it should be posted to the /import or /participants resource.
We are not completely happy with the amount of actions we need to get this going but we cant change the user scenario for functional reasons.
What would be the most restful way of dealing with the "go ahead and process the import" stage (it feels SOAP'y) or how can we change this if necessary?
You uploaded an "import" so you should "process" that import.
Perhaps something like:
POST /import/<id>/process
To this, you would return a status code of 202 Accepted since you'll be actually creating something else