I'm using Audit in Phabricator. By default, users cannot close Audits that were created for their own commits. By setting audit.can-author-close-audit to true it becomes possible for users to close Audits for their own commits.
However, I would like only some people to have this privilege. Is this possible?
I don't know of anyway to allow for this. Audit support in Phabricator is second class as Differential is the recommended way to do code review. The best way to somewhat enforce this is add a certain user or project to commits that trigger audits through herald so that you or other users will be notified if certain users close their own audits. However this may bring about a somewhat uncomfortable social situation when these users figure out what is happening.
Related
Is there a way to protect the database from deletion? I mean it's very easy to click on the "x" next to the root node. This would destroy the whole app and cause an enourmous mess to deal with.
How to deal with this fragility?
EDIT:
Let's assume I have two firebase accounts: one for testing and one for the launched app. I regularly log in and out to use the other one. On the test account I delete whole nodes on a regular basis. An activated password protection would avoid a very expensive confusion of the two accounts.
If you give a user edit access to the Firebase Console of your project, the user is assumed to be an administrator of the database. This means they can perform any write operation to the database they want and are not tied to your security rules.
As a developer you probably often use this fact to make changes to your data structure while developing the app. For application administrators, you should probably create a custom administrative dashboard, where they can only perform the actions that your code allows.
There is no way to remove specific permissions, such as limiting the amount of data they can remove. It could be a useful feature request, so I suggest posting it here. But at the moment: if you don't trust users to be careful enough with your data, you should not give them access to the console.
As Travis said: setting up backups may be a good way to counter some of this anxiety.
Is there a way in the Drupal interface to exclude a specific user from workflow status without having to eliminate his account and make a new one?
Looking over his account, he does not have any of the roles to receive status but he does.
Alternatively, I'd rather be able to somehow search for his actual email in the entire system and make sure he is not listed anywhere. Is that even possible in Drupal?
Thanks
I had to just remove his extra account. He had an older account as a admin buried deep in the users.
We have a client that is using Cart66 on their site. They want the option to accept checks and ship COD but only want admin users to have the ability to perform manual checkout, but in order to track a customers order history they want to place all orders through the site as the customer.
I guess my question boils down to this: is there a way to log in as an admin user then switch to a non-admin user yet keep admin privileges? They are wanting to switch to a regular user but keep the admin ability to manually check out.
They could switch the user to an admin, perform the transaction, then switch the user back to subscriber. Is there another way to keep admin privileges without these steps?
I hope that makes sense. If there is anyone out there that can point me in the right direction I would greatly appreciate it.
Thanks
Honestly, no. I've gotten around this by opening two different browsers. I.e. I'll create two users: the admin account (my normal account), and then an alternate (test) account that's set as a subscriber. I'll use my regular browser and log in as an administrator (my usual account), and then open an alternate browser, and log in as the test account. So I'll have 2 windows open, but each window has a different account open in it. Works just fine. I get to see everything that happens as and admin and a subscriber at the same time.
It would be cool if you could do something like you're describing though - but I can see why you can't - you're getting into user roles and capabilities that would make no sense if you could do what you're describing.
I suppose one possibility would be to use the current logged-in-user's ID, and write a function that would strip front-end capabilities (visually make them appear to be a logged-in subscriber), but it's a lot easier to just open two different browser windows.
Is there any limitation in Tridion that would stop more than one physical user sharing a single Tridion account for logging in?
Tridion as far as I know wouldn't end the other session or log a user out if both logged on at the same time, for instance.
Our client is getting close to their licence limit and is looking several users sharing a single account. From a business perspective they'll lose the ability to really know who changed what - but there's no workflow in place.
Is this in breach of the Tridion licence to do this?
Cheers
Tridion is a stateless application, so although there is authentication there is no concept of log-in or log-out. You could have problems if different users of the account tried to change the same item at the same time (have seen this in training session where a single account was used).
Yes, it would be a breach of the license conditions - typically this is done on a named-user basis, unless unlimited users were allowed (which would probably mean you wouldn't need to do this anyway).
You're right that it would probably work from the software point of view.
But I think we can guess the answer to your license question. After all, it sounds like they are looking at doing this to avoid paying money to SDL for the actual amount of users that they have.
I'm not a lawyer but that doesn't sound like a good idea...
AFAIK SDL Tridion uses sessions bound to the browser, so it doesn't matter from that point of view how many of those session use the same user account. There is no option of loggin out, or ending a session for that matter either.
So yes multiple users can use the same user account but they pose themselves a risk. If user A checks out an item and starts working with this, user B (using the same SDL Tridion account as user A) can also open that item and will not get it in read-only mode (like you would if you were using a different account). So the versioning and locking of items are now bypassed and rendered useless.
Lastly this is indeed violating the license agreement as specified in the contract (unless there is an unlimited number of users granted in the contract).
I need to prevent all CRM Online users from logging in for a short period time while I perform an upgrade to some of the customizations.
Disabling each user is time consuming and I believe that disabling will require a new "invitation" after the user is re-enabled.
What is the best approach for this?
I would suggest trying to disable the Business Unit. But you cannot do this if you only have one Business Unit defined.
http://rc.crm.dynamics.com/rc/2011/en-us/online/5.0/Help/source_set_BU_EnableDisable.htm
According to the online documentation above, disabling the BU will disable login for all users.
We would have to deduce a suitable methodology for managing this, for instance having a single user in a second “administrative” BU that you would login as that user to manage this process.