I am going to implement the User Log history into my project (OrangeHRM). I am using Doctrine.I found some plugins for Log and History but those plugins use Propal but I want in doctrine.Is there any plugin for this?
If no then I am going to implement this on every Action (Add/Edit/Delete). This will be take too much time to find and enter code. I want that is there any Event that can tell us the Add/Edit/Delete Status so that I just enter my Log history code in that Event.
Related
We are trying to configure the application DriveMeTo to use the linkedin login.
When we try to configure "iOS bundle identifiers:" with "it.drivemeto" value in the linkedin site app configuration page, on clicking Update button we receive the error "Your changes could not be saved right now, please try again." .
Probably the issue depend on the fact that this bundle id is already taken from a previus accout where we have no more access to. Please may you suggest a way to fix this issue? The bundle is legally registered form our company.
Waiting for your answer we wish you a good day.
I want to allow access to certain content to certain users for a limited time,
using a 'Dynamic Role' in Plone 3 ( http://collective-docs.readthedocs.org/en/latest/security/dynamic_roles.html ).
To this end I've created an add-on with a copy paste of example code - except that for now getDummyRolesOnContext() always returns my role.
But Plone never calls, or instanciates my DummyLocalRoleAdapter, and obviously my users never get the role assigned.
Here's what I know so far:
My dynamic role is defined in a rolemap.xml and get's created upon add-on installation.
My add-on is being imported - an exception on it's first line prevents Zope from starting
None of DummyLocalRoleAdapter are being called - I've spiked all of them with warnings and exceptions.
The adapter does get registered.
How do I continue debugging this - what's the magic part I'm missing?
Thanks!
My guess is that you need to somehow activate borg.localprole PAS plug-in in acl_users:
https://github.com/plone/borg.localrole/blob/master/borg/localrole/utils.py
There might have been borg.localrole add-on installer entry in the past, but now there doesn't seem to be one. My guess is that you need to call the actions from borg.localrole add-on setup code manually in your own add-on.
acl_users when borg.localroles is correctly installed:
When I first created my Plone (4.1) site, I made a mysite.policy add-on to include some custom users and a custom workflow.
I need to make some corrections to both the workflow and the permissions. I updated the src to include these changes, but updating the package in through the Plone add-on manager (uninstall - install) does not work. As soon as I uninstall the status of all my entries switches to "local policy", so I cannot get the fine-grained status setttings back when I reinstall.
Also, the user permissions do not seem to change. Possibly because they were already created at set-up of the site. But I cannot figure out how to code a change to permissions versus a setup of permissions in the rolemap.xml. I assumed that whatever is in that xml is what rules my plone world, but that does not seem to be working.
So far I cannot find anything about this in the manuals and books I have at hand. Any hints how to solve this? Perhaps the only way to go about this is a series of manual changes through ZMI, but it is so much less elegant to do it that wat.
There's plenty of options. I'll try to describe a couple of them.
If your changes include only changes in Generic Setup profile of your site policy (./src/my/site/policy/profile/default/-files) and you don't want to automate the upgrade, you could simply update the profile-files and re-run those specific import steps for your policy:
Open ZMI (site/manage) for your site and look for portal_setup.
Select Import-tab when on portal_setup.
Select the profile of your site policy from Select Profile or Snapshot-list (the title of your profile is defined by the registerProfile-directive in configure.zcml or profiles.zcml of your policy product).
Click to select import steps for Role / Permission Map and Workflow Tool.
From the bottom of the page, deselect Include dependencies.
Click Import selected steps-button.
Go to portal_workflow-tool on ZMI and Update security settings, if your workflow update should modify permission in existing workflow states.
These steps should re-import only the selected import steps of you site policy product's Generic Setup -profile. Re-importing individual steps this way should be quite safe, but be careful: accidental clicks at portal_setup screens may have unpredictable consequences.
These steps can also be automated by defining something called Generic Setup Upgrade Step.
I hope that the default Generic Setup -profile of your site policy product includes metadata.xml with line <version>1</version>.
Update that line to <version>2</version>.
Open the zcml-file with registerProfile-directive and, after it, add
<genericsetup:upgradeDepends
source="1" destination="2" sortkey="1"
title="Upgrade my.site.policy (1 to 2)"
description="Upgrades my.site.policy's default profile from version version 1 to 2."
profile="my.site.policy:default"
import_steps="rolemap workflow"
run_deps="false"
/>
These steps should register such an upgrade step from the profile version 1 to 2, which re-imports steps rolemap and workflow (rolemap.xml and workflows.xml). You should be able to run the upgrade step from the Plone Site Setup's Add-ons-screen, where there should now be an upgrade button after your installed policy product.
As mentioned by #toutpt, the Collective Developer Manual has more examples on upgrade steps. If you have ever wondered, why it's recommended to use integers in metadata.xml, usually independently from the product's release version number', this is the reason :).
Any changes that need upgrade must be shown by increment the number in profile/default/metadata.xml (keep integer). Next you have to write an upgrade step. It will add an upgrade button in the addons control panel.
Please follow this tutorial to learn how to create an upgrade step: http://collective-docs.readthedocs.org/en/latest/components/genericsetup.html?highlight=upgradestep#upgrade-steps
I am new to alfresco.
Is it possible to get list of all the documents created and uploaded by the user and populating these values in a custom dashlet?
If you look at http://localhost:8080/alfresco/service/index it will tell you about all the webscripts currently available. If you can, you probably want to use an existing webscript to get your data, though writing your own one isn't too bad - this would get you started.
I think that for your use case, the "user feed" should give you the info you need. Visit http://localhost:8080/alfresco/service/script/org/alfresco/repository/activities/feed/userfeed.get when your repo is running and it'll tell you the details about the webscript
Hmm If it's in Share then you have a content tab on the user profile, which shows all the users content. You can load that webscript into the Dashlet.
Suppose I have two content typs, "Job Listing" and "Job Application". A job application has a field (using the CCK module) to reference the job listing (a required field). Suppose the job application has a field "Status" with values like "new", "accepted", "rejected".
I would like to set permissions so that the job application status can only be set by the creator of the job listing it corresponds to. If there is an addon that can do this great. I would also like general direction as to how a custom addon might implement this.
(I am following the scenario in Ch. 3 of O'Reilly's "Using Drupal")
I don't know if there is a module for this but this can be done pretty easily with some custom code though.
Use hook_form_alter to add your own validate handler to the node_edit form for the application content type.
Check to see if the value has changed
Set an error is user isn't the creator or has the administer content permission.
You're done.
Directions by googletorp are on the right track but you will have to take care of some more permissions also.
Remove the edit own permission for the application content type.
Also you probably do not want author of one job listing editing the applications in response to some other job listing. This is hard to do with any built in permissions. So check in the form_alter hook that current user is the same as the author of the job listing to which the application being edited is connected to.