In our Plone site we have people making comments on documents. The person who wrote the document will need to respond to the commentor. I created a group for writers and gave them the Reviewer role. The problem I have is that all the writers in the group can see each others comments and can approve or delete each others comments. I need to make it possible for the writers to only see their comments. Would I do this with workflows? or is there an easier way?
To a zeroth approximation, I'd give the permission Review comments to the Owner (pseudo-)role in the ZMI Security tab, which will only them give permission to approve/delete comments. (This permission is not managed by any of the standard workflows.)
This would also lead to pending comments not being visible to others; I'm not confident Plone's default commenting mechanism is equipped to closely control visibility of comments once they're approved, though.
Related
I am working on a CRM 2013 implementation and I have the following requirement:
Salespeople should be able to view all notes within their business unit. They should not be able to delete any notes and they should be able to modify only notes that they created.
I am not new to configuring security role permissions and I have no trouble achieving similar functionality with other entities. Notes however have stumped me.
In the Salesperson security role I configured the note entity as follows:
Read: Organization,
Create/Write/Append/AppendTo: User,
Delete and Assign: None,
The result is that salespeople were correctly able to see all notes. However they were able to delete and note and edit any note within their business unit.
I then did some reading and it seemed that the "Profile Album" permissions under Custom Entities was also somehow related to wall notes. I configured Profile Album as follows:
Read: Organization,
Create: User,
Others: None,
At this point my Salesperson use was no longer able to delete any wall notes. However, they could still edit wall notes owned by their business unit. Just for fun I removed edit permission entirely from the role and the salesperson was correctly unable to edit any records including their own.
Is there a bug with the notes write permission so that the user level confers business unit privileges?
I ran into a similar issue, and this is what I found:
Since notes have a parental relationship to its associated record, the permissions seem to flow down from the parent record.
I ended up creating a plug-in to prevent any user who didn't create the note from editing it, which was a huge pain.
Furthermore, there didn't seem to be any way to prevent users from trying to edit notes on the notes wall, so I ended up doing some HTML manipulation to prevent users from trying to edit notes that they hadn't created.
The business users ended up being happy with the functionality, but it did cost a little bit of time and money to get to the solution. See the attached screenshot.
We've had facebook comments via the social plugin implemented for some time on our website, on a per-article basis. Occasionally, an article 'dumps' all its comments. They still show up in the app moderation back end, but none of them permit 'Visit Website'. They may be approved, but they no longer appear on the article page, though they will still show up on the poster's facebook if they chose to post to their wall. This seems to happen the most on 'noisier' articles, but I suspect that to be the result of more posters meaning more people to notice the disappearance. The article will then accept new comments normally, but all old comments seem to be permanently lost.
Obviously, changing the canonical URL for the article would cause this. However, we've had it happen on articles I do not believe changed. Is there anything else that can cause comments to become disassociated from the article that I could possibly correct? Can this happen if the URL (not canonical!) changes? For SEO purposes we have the article headlines in the URLs, but the plugin is set to a canonical url without the headline to avoid disruption if the headline is updated. Is that enough?
You should think of the URL for an article as a unique string identifier for the comments plugin. The URL defined should be unique (only for one page). The formatting of the URL doesn't matter. However, even the slightest change in the URL will disrupt the comments plugin because now the string is technically different. I'm not sure what else could be causing your issue.
It may help to reread the documentation on the comments plugin here: https://developers.facebook.com/docs/reference/plugins/comments/
Is there any tutorial available for how do i add custom fields on front end check out step like PO number,Job name , customer comments etc as well as in admin->create->order.
My usual motto is to find (and buy if needed) a module that already has the functionality you seek. Especially when the life of this project involves version upgrades because then you can seek a pre-packaged solution from the provider.
I regret every bit of custom code I have added to our Magento install. Because now I've got to maintain the site to just keep working in addition to figuring out my hacks. Time to devote more time to replacing hacks with off-the-shelf extensions, which would have been much faster in the first place.
I know this attitude goes somewhat against the stack overflow thinking of I can do anything, but really, Magento's job is to enable someone to do less work.
Two years later, an update: after the gentle poke of a downvote (probably for appearing to shrug off the question), I am back to revisit and share some of what I've learned. The programming aspect of additional fields is the concept of persistence of the data.
If you're ok with the custom fields only appearing in the transactional emails following the order, then the task is as "simple" as adding the fields to the form somewhere and then updating the controller to to catch and insert the post data into the email. You can use a custom variable in the back end to readily expose this to the email templates. And a Magento SE on programatically creating a custom variable.
Getting persistence into the back end requires adding database fields via an installer in your module. The iCoreThink blog lays out the steps clearly and explains why, how to confirm your work, and then provides real-world implementation, like displaying to the customer in their account. The "other blog" mentioned below has a great example of this, though his example is specifically related to billing and shipping.
Resources from my upvotes and bookmarks:
» This iCoreThink blog post is my favorite reference so far and what I'm following now.
» I was using Templates Master's FireCheckout which includes their own checkoutfields module, but I've abandoned their single view checkout for the flow of Magento's one page checkout. I'm now trying to adapt their checkout fields (and use their controller) into my template for checkout.
» I thought for sure Alan Storm wrote an article about Checkout custom fields, but I don't see one.
» This Magento SE lists a couple blogs and a paid extension. The excellence blog is ok, but his style is too rote for me and I don't learn anything. The other blog discusses the procedure for building your module and installing the database fields.
» The unexpected-IT blog demonstrates and informal hack to add the code to core files (but sadly doesn't show how to override those files by copying them to app/code/local) and the steps to manually perform to get the column and fields added in the database. Apparently is perfect for 1.4 and below, but comments seem to explain what to do for 1.5 and up.
This last hack-ish change is my personal favorite as it seamlessly adds the extra bits into existing Magento admin pages and "feels like" less work. Caveats: I wouldn't do this without using version control and it will absolutely break if any core code changes happen between version upgrades.
when using Requirement Management application, some ppl say, dont show your users, those areas which are not accessible for them or no permission, only show the accessible section... It doesnt sound good to me, what do you guys think?
It depends.
How much stuff do want to show? One problem many systems do have is information overload. So less options would be better.
How experienced are the users? Sometimes it might be better to have a consistent interface for many users to help novices recognize things they see at other screens.
Off the top of my head I can think of three reasons why you would want to avoid showing your users areas that they do not have access to.
You're constantly reminding them that there are features that they cannot use. This can lead to feelings of not being trusted or of not being important enough.
You waste users time. In some implementations I have seen of this the user is allowed to complete a task, for example filling out a form, and only when they submit it are they informed that they have insufficient privileges. This can lead to frustrated users.
You distract the user. Best practice is to put the bare minimum amount of information and choice in front of the user (there are exceptions to this rule). Enable your users to get their specific job done, rather than distracting them with the possibility of the option of getting all the jobs done.
If you are worried about inconsistencies in your user interface then you should probably take another look at the way you have laid your UI out and how you have segmented the tasks.
Generally speaking you should break your applications into sections of tasks (use-cases) with the permissions being tied to the particular task in the application.
For example if User A can only pull reports from a system then they should only be offered the option of going to the "pull reports" section of the application. If User B can pull reports and add orders then his screen should offer him the option of either "adding a new order", or going through to the exact same "pull reports" screen as User A. These screens shouldn't differ between the users in most cases. Their menu/navigation options would be contextual based off their permissions, and User A would never even have the option of clicking the "add new order" option.
There are obviously instances such as when certain users have a delete privilege then they are shown a delete button when other users only have the read permission. In this case your UI would differ from user to user but in an appropriate and contextual manner.
Somebody once said that an interface is done not when there is nothing left to add, but rather when there is nothing left to take away.
I would like my Joomla website to behave like this:
All users can view new articles
When new articles are published over sometime (say 1 week), they become
old articles. (This part can be done
manually, if there are no extension
for it.)
Then,
Normal users can only view the title of old articles. If they click them, they are asked to pay.
Paid users can view old articles.
All users can search against new and old articles. But as mentioned, only paid users can view old articles.
What kind of extensions do I need?
Thank you very much.
Updated:
I asked AEC (Account Expiration Control) support about my requirements. Here the reply I got:
AEC is not an Access Restriction
component but a Membership Manager
that happens to be good at telling
other components what they should do.
Many users extend the Joomla
usergroups with components like
FlexiAccess, JACL or JUGA. With
extended usergroups (and, in this
case, Access Levels), you can restrict
access to articles, categories and
menu entries. I would advise that the
best idea might be to check out the
ACL components - AEC can cater to
pretty much all of them so that it's
more of a question whether the ACL
components can do what you want to
achieve.
Also - archiving articles is
completely out of scope for AEC, so
you'd have to find out how to
accomplish this in your content
management.
Updated 2:
I think AEC might be the one I need.
You can do this by using Access Expiration Control. You will have to do the follwing :
Create plans for your users and handle the plans ( Free, Monthly, Life time .. etc ) , the payment and the access control.
Create menu item for the archived articles.
Use ACE to make accessing this part of the site restricted to payed members.
Profit $$$
This is how I see how it could be done ... I've used on many sites but not for archived contents so I would recommend you contact the developers at their site and ask them about your case.