I am new to sense net.
In sensenet on the set permissions ui for a specific content we have multiple entries related to versioning: Open and Open minorand I don't understand the difference between them as they are related to same operation. I want someone to see all the minor versions except for drafts.
I tried to select and deselect these two options and I was only able to see major versions for specific content or none of them.
How to apply the above mentioned scenario and how is it related to these two type of permissions?
Open permission means that the user is allowed to open the major version of a Content and to see Field data of the Content
Open minor permission means if the user is allowed to open minor versions of the Content and see corresponding Field data
Since draft is also a minor version of a Content it is not possible to filter out drafts from the minor versions.
Vistors in general are only allowed to view last public versions of a content. This is controlled by the Open minor permissions: a user that does not possess the open minor permission for a content will only see the last public version of a content, and will never see any changes that correspond to a draft version or that are not yet approved.
The other important thing here to bear in mind is that if a document gets rejected it does not mean that the document is not visible for the public. It only means that the last version that was rejected will not be visible to the public. So for example:
1-Set approval on a document library to true.
2-Upload a document - it's state will be pending for approval (you can check it out on versions tab): only users with open minor permissions will be able to see it.
3-Send it to approval using the approval workflow. If the approver rejects it, it still not be visible for the public - or users that have no open minor permissions. If the approver approves it, it will be visible for the public.
4-Edit the document and make some modifications. It's state will be pending for approval once again. Users with no open minor permissions are able to see the document but not the latest modifications: that is they see the last public version, and not the one that is pending for approval.
5-Send the document for approval. If the approver rejects it: users without open minor permission will still not be able to view the modifications that have been rejected: only the last public version. If the approver approves the document: users without open minor permissions will finally be able to see the modifications as well, because at the moment of approval the last (yet pending) version became the last public version.
reference:http://wiki.sensenet.com/Versioning_and_approval
Related
I have a script that is using manage_setLocalRoles to assign a specific role to certain users specified. See below for snippet
context.manage_setLocalRoles(username, (‘Editor’, ‘Reviewer’))
context.reindexObjectSecurity()
After that script runs, you can go to the Sharing tab of the page and see the user specified with Reviewer and Editor checked. However, that user does not have any of the rights that go with those roles.
For testing, I have performed the following checks
context.getMyRolesInContext() does not return any of the roles set above.
context.get_local_roles_for_userid(username) only displays the roles set above, and not any global roles set (when testing as site manager and the like).
context.portal_membership.checkPermission(“Modify portal content”) returns a False.
With Editor role I should have Modify portal content permission. I did verify in the workflow of the content type to make sure the roles are set correctly for the permissions in each state. And as a double check, I ran this script on the content.
username = context.getCurrentUserName()
roles = context.rolesOfPermission('Modify portal content')
member = context.portal_membership.getMemberById(username)
for role in roles:
if role['selected']!='':
print role['name']
print member.has_role(role['name'], context)
return printed
This was my result:
Editor
0
Manager
1
Reviewer
0
Site Administrator
0
Those results are from my site manager role, but after I ran the manage_setLocalRoles on my user to add Editor and Reviewer.
Any thoughts as to why the roles aren’t recognized everywhere? Or am I using the wrong process for what I am trying to accomplish?
NOTE - I have already looked at this answer, and as my code reflects I am already doing what it suggests.
EDIT
Adding versions per comment. We have quite a few add-ons, but none of them seem like they would be related. Mostly jQuery integrations, and types like PFG, True Gallery, FullCalendar. We are using a custom theme and all custom content types and workflows. Excluding the content type I am currently creating for this project both the theme and all other content types were created before I got here. The types are Archetypes extensions.
OS - Red Hat Enterprise Linux Server release 5.11 (Tikanga)
Plone - 4.3.2
Products.ATContentTypes - 2.1.13
AccessControl - 3.0.8
The problem boiled down to case sensitivity. Our users are fed from an Active Directory plugin. Some of the usernames are all caps, and others are all lower. Somehow the username being used in my set roles command were always lowercase. As a result, user was getting the roles, when it should have been USER.
My Solution was to first get the actual member from portal_membership, then grab the username from the member.
pm = getToolByName(self, 'portal_membership')
user = pm.getMemberById(username)
self.manage_setLocalRoles(member.getUserName(), ('Reviewer', 'Editor'))
self.reindexObjectSecurity()
Apparently getMemberById() is not case sensitive, and it returns the correct username in the correct case. So I was just missing that extra check/filter.
Is there a way to retrieve the current user's information (i.e. login/password) so that it may be used to automatically fill in forms during the install?
I do not know where to start my searching.
I would agree with the answer to a similar question I found here:
"Windows will never, ever give you the user's password. You will have to
prompt the user to give it to you."
If this were possible, it would present inherent security problems. Consider what else a program could do if it could obtain my account credentials programmatically just because I am running the program.
If you just want the user name though, it looks you can get that with the LogonUser built-in variable. There is a list of built-in variables here if you are interested in what else is available.
I have a website in progress where users create posts in a feed, and may have many feeds. Their profile will display a default feed of their choosing.
The 3 tables in this paradox are "accounts", "profiles", and "feeds".
An entry in profiles contains additional information about a user. This is in a separate table because it may be modified more often, and many queries use the accounts table without needing this information.
A field in accounts (profile) must reference a profile. I've done this, instead of having profiles reference accounts, because otherwise an account could exist without a profile. A profile existing without an account would be the result of a deactivated account (provided the user explicitly chose not to have their profile removed from the site).
A field in profiles (default_feed) must reference a feed. This may be changed often, and isn't needed by most queries, so this seems a sensible place for this data.
A field in feeds must reference an account; all feeds have a creator.
You may be able to see my problem already, but I'll elaborate:
I can't make an account without making a profile, which I can't make without making a feed, which I can't make without making an account, etc...
Must I give up the functionality of profiles for deactivated accounts (which wouldn't be a huge deal, but I'd like to know if there's another way), or is there a sensible trick that will allow me to solve the paradoxical nature of this relationship?
EDIT: I've realized I could simply set the default_feed field so it's allowed to be null, and have the application handle this special case (which should never happen anyway, since a feed is created with the account) with a "this user has no default feed" message. I'd still like to know if I've missed a more creative solution though.
One simple way to break the dependency is to make default_feed in profile nullable.
Start by creating a profile with the default feed set to null
Create the account that references that profile.
Once the account is set up, create the default feed with the account that has been created as owner.
I'm using the AuthzPolicy-plugin to manage the permissions in a trac-env. Now I like to set a permission that disallow all users except for the admins to view tickets with a specific status.
I try a lot such as the following entry in the authzpolicy.conf:
[ticket:*/status:new]
#administrators = TICKET_VIEW
* =
Does the AuthzPolicy-plugin provides permission-setting for tickets with a specific status, owner or something else?
mutetella
Trac's permissions system is focused on the component level. You can turn on or off access to an entire component, but not to sub-content inside of that component.
That being said, you can create a plugin that emulates a more fine-grained permissions system. The plugin would need to implement IRequestFilter and inspect the URL of pages when they load. It would extract the ticket number from the URL, look up the ticket details in the database, and determine if the current user should view that page. If the user doesn't have permission, the plugin would re-direct the request to an error page. This is not too incredibly difficult to do (I've done it before to guard a specific wiki page), but it's hard to maintain because it's a separate permissions mechanism that's completely independent of Trac's permissions system.
TracFineGrainedPermissions can use any property represented in the resource path.
Revisions do, so you'll find an example explained as "John has BROWSER_VIEW and FILE_VIEW access to only revision 1 of 'somefile' at trunk/src/some/location only"
So the direct answer to your question is No, you can't do the same depending on ticket status, because all tickets look the same from the resource URL regardless of their status, sorry.
I agree, that you can resort to implementing a custom policy as already outlined by bta as a last resort.
According to the Apple In App Purchase Programming Guide:
The App Store creates a separate transaction each time it renews a subscription. When your application restores previous purchases, Store Kit delivers each transaction to your application.
Let's imagine my app subscription is client-side-only (no server component). The simplest way to verify that subsequent renewals have been billed seems to be restoring previous purchases every month.
However, this pops up the user's iTunes password prompt every time you call restoreCompletedTransactions which seems like bad user experience. Is the only recourse to use the server receipt verification code (along with the new "shared secret")?
The App Store calls the paymentQueue and posts a transaction each time it auto-renews. The transaction is posted with transaction.transactionState==SKPaymentTransactionStateRestored.
The issue is that unfortunately this gets posted only to one device. A second device does not get the posting. Therefore, to detect the auto-renewal, or rather to detect the lack of an autorenewal and deny any device a continuing subscription, you have to do a restoreCompletedTransaction or "http post a 64-bit encoded JSON containing the last transaction". If the fomer, the user needs to give their password; and as you point out, that's intrusive. If the latter, lots of additional coding is required. So, my question in answering your question is...why doesn't StoreKit have a command:
(does not exist) - [[SKPaymentQueue defaultQueue] restoreAttachedTransactions:(NSArray *)transactions];
This command would flow just like a restoreCompletedTransactions but it would only restore the attached transactions and, most importantly, it would not require log-in by the user. It has the same security protection as the "http post a 64-bit encoded JSON containing the last transaction" and it allows the entire In App Purchase process to be done in StoreKit rather than requiring web posting code.
If this makes sense to you, please suggest how to get this to Apple....thanks.
If you have no server component, the only place you can store this information is in a local file/database/config
The restoreCompletedTransactions option is there for when there is something wrong with your local database, you should put a button somewhere on your advanced settings panel to restore all previous transactions.
So, you will have to trust the data you store locally. Normally, this is safe as you cannot change your local filesystem (unless you jailbreak). If you don't want to trust your users like that, you can optionally encrypt it...