In Maximo 7.6.1.1:
Is there a way to batch-delete route stops from an existing route?
Delete all route stops from a route
Delete route stops from a route that meet certain criteria (filter, advanced query, or WHERE clause)
Note:
I have thousands of route stops per route. The solution needs to delete all route stops that apply -- not just the route stops that appear in the first page of the results.
An automation script can do this.
Create a Sig Option in the Routes application with Advanced property "for use by user in the UI".
Add the Sig Option to the Select Action menu or drop a pushbutton on the main tab of Routes with an event equal to the Sig Option name -- so a user with permission can see and click the Sig Option.
If desired, use selection columns from other apps to add one to Routes.
Grant the Sig Option to appropriate Security Groups.
Create an autoscript with an Action launch point against the routes object, and name the Action the same as the Sig Option. You could make the script look for routeStopMbo.isSelected() or just cycle through all the Mbos in the routeStopSet on the assumption that they have survived the user's filter.
Related
We currently have a number of workflows in our organization that require users to add an item to a list via a form, but then not be able to edit that item unless given special permission to do so.
For example a user submits a leave of absence request and it is routed to their manager. The 1st level manager might approve this request and the workflow continues. While the request is in the managers hands it cannot be modified by the original submitter, however if the manager rejects it or requires revision the original submitter should then be able to edit.
Is this possible? The best strategy we could come up with for this is multiple Lists to handle the different levels of security required for this. Are there better ways of doing this?
SharePoint seems to have a very open concept of security within an SP site and maybe were just trying to fit a square peg in a round hole.
Thanks!
How about Remove permission for that user/for all user using workflow itself?
http://spcycle.blogspot.jp/2012/01/how-to-create-workflow-to-change-item.html
http://shareapointkiran.blogspot.jp/2012/06/addremove-permissions-using-sharepoint.html
And then give it back when manager approves/rejects
I had a similar problem and solved it with a quick and dirty solution.
In our case this quick and dirty solution might be even easier.
You could add a hidden field that has an default value of for example 0.
Then you add a (formating) rule to one of the fields that should be deactived.
The rule should deactivate the field if the value of the hidden field is not 0.
This rule can be copied to every field that should be deactivated too.
Now add a set field action to your workflow that set the value of the hidden field to something else than 0, for example 1.
To make a hidden field you can define formating rule with a condition that is always true.
Now if someone creates a form the workflow will set the value of your hidden field to 1. The rule of the fields that should be deactived will now deactivate the fields.
Hide the field
Deactivate the field rule
In sailsjs blueprint api,By default, action route responds to all four types of requests - GET, POST, PUT, DELETE. I would like to deny only certain types of request to a route, while allowing the others to go through. For example, I may wish to accept only POST requests to the bar action at /foo/bar, while denying GET, PUT and DELETE requests to that route.
Although Policies can be used to restrict controller actions.
FooController: {
bar: false,
},
But,Here it denies all 4 types of requests or allow all 4 types of requests based on the same condition. What I want instead is to always deny 3 out of the 4 types of request, while always allowing the 4th type to go through.
Can this be done without resorting to disabling Blueprint and manually inputting the routes into /config/routes.js? If so how?
This is one for your routes file (/config/routes.js), and not your policy file as you have identified.
'POST /page/link': YourControllerName.ActionName,
'GET /': YourHomePageController.ActionName,
'PUT /login': UserController.login
The first 2 are examples showing the syntax. The final example shows how this would look in a typical setup controlling a login form submit. If you wish to allow multiples through e.g. POST and PUT then just add another line in with the same controller.action but change the method.
For further examples and also other syntax that can be used take a look here:
http://sailsjs.org/documentation/concepts/routes
Once you have the routes you want, you will then need to turn off the blueprint methods, which if you leave on will over-ride these routes and still allow access through.
Go to your config/blueprint.js file and change the following items:
actions: false
rest: false
shortcuts: false
Once again, further information on what these do and how they can be used can be found here:
http://sailsjs.org/documentation/reference/configuration/sails-config-blueprints
How to code or make user even script making lines department mandatory if Expense GL codes is selected in the transaction?
You will most likely want a Client Script for this that uses the validateLine event handler.
This will allow you to prevent the addition of the line at all if it doesn't meet your acceptance criteria. You cannot specifically modify the column to make it "mandatory" in the UI (i.e. add an asterisk to it), but the script can enforce the logic so that the line does not get added and alerts the user appropriately.
The validateLine event handler function you choose just needs to check whatever conditions you have and return false if the line should not be added or true if it should be added.
The only way to do this in a User Event script is to throw an Error, which is intrusive and usually means the user will lose all the data they just entered, returning them to a blank form.
I'm trying to have my menus automatically change according to settings in my code so I don't have logic duplicated in my templates. Right now I use the route names to generate the urls with request.route_path(name) and determine what the current page the user is on with request.matched_route.name. My problem now is that I want to have different permissions on different views and automatically hide menu items that the user doesn't have permission to.
One of the major difficulties is that you can have multiple views for one route. But even if there's only one view associated with a route, I can't seem to find any simple way to retrieve it.
I'm using URL Dispatch. Is this something that'd only be do-able with traversal?
Normally I use a combination of the following patterns for this:
My views are organized into classed
The base class has a basic _menu which is a list of (menu_title, route_name, params) where params is an optionally present dict. When in the template I can use a menu property that builds the menu from the request and the above attribute.
In the template create a function that iterates over theses entries, shows each but checks with something like has_permission if the view is actually allowed.
These ideas should get you started on a dynamic solution. It works fine for me, but it might require some more tweaking, for example, I attach another value "active" to the generated menu based on the current route.
I've created my own solution with a custom entity of type activity. I'd like to show a message whenever a new instance of it is created using an existing contact but not allow the user to create one, if only attempting to do that without going via contact.
Basically, my aim is that it won't be impossible to just create that activity (the form will be hidden directly at any attempt except for one way only). The user will have to go to contacts (or leads etc.) and in there add and create an instance of the custom activity entity. That way, I can assure that the field "regarding" will be filled out already.
I'm guessing that I need to detect somehow that the opening of the form is a creation attempt. How can I do that?
Also, as it is now, the user can't create a contact-less activity of the custom type because it doesn't appear on the menu with other activities. I must have disabled it somehow but I have no idea how. Anybody who has one?
You could do this a bunch of ways but the easiest would probably be to:
Make the regarding field read only.
Make the regarding field mandatory.
That way if a user opens a create new form they wont be able to set the regarding and because its mandatory they wont be able to save the record. When they open via an existing contact the regarding field will be mapped automatically. That said in this case just making it mandatory my be enough.
(As a side JavaScript can be used to identify the current form state, but I'm not sure how useful that is here).
In terms of where custom activities appear, by default mine show in a number of locations, for example:
CRM > Workplace > Activities > Ribbon > Other Activities > XXX.
CRM > Workplace > Activities > View Selector > XXX.
They don't show under the left hand navigation of the workplace because they are grouped under 'Activities'. I'm pretty sure these are all the default settings.
You can exercise greater control by editing the sitemap, where you can put pretty much anything, anywhere.
In addition to Mr Wood, I'd like to show you some code. It works as supposed to but I'm not sure if it's optimal.
var foo = function () {
var whatIsGoingOn = Xrm.Page.ui.getFormType();
if (whatIsGoingOn === 1)
alert("Let there be an entity!");
else
alert("Not a creation...");
}
The other states' (deletion, update etc.) numeric values are listed here.
Answering the second part of your question:
When you create a custom activity you can choose whether to have it appear in 'normal' Activity menus or not by checking the box at the top right of the entity form. This is a once-only choice as far as I know and can't be changed later.
For your setup, I would suggest NOT checking this box, so it does not appear in the activity menus to avoid users even being tempted to do it that way.
Instead, add an explicit relationship to the activity N:1 to Contact, and another N:1 to Lead. Use this relationship to add your activity to the left navigation of Contact and Lead forms, or add a grid for them (depends on how you want to use this and if you need to filter the view to something other than the default "Associated View").
When a user navigates to this section they will see if any previous activities of this type exist, and be able to add a new one. BUT this means that the child record is a child via this relationship, not using "regarding", so use a script on the form for the activity so that if Contact is filled in, it is copied to Regarding, and if Lead is filled in then that is copied. If neither, then use an alert or other means to warn the use that something is wrong (see comment earlier). If you want Regarding to be read-only but filled in by script, you will need to make sure to use the force the value to be saved:
Xrm.Page.getAttribute("regardingobjectid").setSubmitMode("always");
You must have the lookups for Contact and Lead on the form to be able to use them in your scripts, but you can make them not "visible by default" so they are there but not seen by the user (and taking up no space).