I'm realizing a theme with liferay using velocity. I would like to add some functions to the theme homepage only in the case the user logs in the portal for the first time.
How can I use velocity (portal_normal.vm) to achieve that?
As stated by #Olaf Kock it is not suggested to use the business logic in the theme section.
But, If you want to do it anyway then Liferay provides a set of Velocity Variables that can be accessed in the Themes. Which includes the User details too.
These are some of the User related Variables available globally in themes,
$user_id,$is_default_user,$user_first_name,$user_middle_name .... $user_login_ip, $user_last_login_ip
You can check out more at : themes\_unstyled\templates\init.vm inside ROOT.WAR.
So, For your specific purpose here you can use $user_last_login_ip. If the value is null then it would be the first time the user has logged into the portal.So, use this inside the portal_normal.vm,
#if (!$user_last_login_ip)
... do stuff here if the variable is null
#end
And, Alternately you can fetch the User last login date using and check null to ensure whether it is his first login,
#if (!$user.getLastLoginDate())
... do stuff here if the variable is null
#end
Don't add this to the theme. Rather have a separate custom LoginAction for this. This will be executed on every login (you can choose pre- or post-login, I'm assuming that post-login will be appropriate) and should find some more information than I linked on this topic all over the net.
A theme is made for look&feel and should not contain any business logic - especially not when it's for a one-off purpose.
Related
The technical term given in many articles for this is Template Variables. I am trying to understand how we can find the variable name given in the controller for a specific field of Shopware 5 front end (ex. Product Name)
For example, I can see the template variable for article name has been given as $sArticle.articleName. I found this when I checked the source code manually.
Let’s say I want to find the discount value given for particular product, How can I print this on my theme? What variable I should use and what is the easy way to find it.
I can assign values from back end for all the variables but my question is how I can access them on my theme file when I update my theme when it comes to technical development side.
Please Note: I am trying to understand the shopware5 technical side.
Using the {debug} function will usually give you a list of all assigned variables. This list should also include a variable $Controller which will give you a hint to the currently related Controller.
Unfortunately you are not able to identify where the assigned variables come from. Due to the event driven architecture of Shopware the variables can be assigned to the view after the request has been dispatched to the related Controller. This means that variables might he assigned through third party plugins as well as specific event listeners and store front decorators (in Shopware 5).
Kind regards!
If you want to use your variables inside the template you have to write a plugin and assign your controller-variables to the view.
Check out Globale Variablen im Template verwenden in the shopware documentation.
If you want to use see which variables are allready assigned, you can use {debug} in the template. Also {$sArticle|var_dump} is really helpful, if you want to debug a specific variable ($sArticle} in this example).
You have to known that shopware assigns the members of an object to the view.
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).
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
I have column Status (0= Default, 1=Accepted, 2=Rejected), when first creating this list
I want to hidden this field and filling it with default value (0).
On edit form, I want to hide this column from updating if user role is not HelpDesk.
Thx
For your first requirement, you could use SPUtility.js (full disclosure this is a library I maintain). You would basically put some JavaScript in a Content Editor Web Part on your NewForm.aspx page:
SPUtility.GetSPField('Status').Hide();
If you want to change the value (if you don't have a default specified in your list settings) then you could do:
SPUtility.GetSPField('Status').SetValue('Default').Hide();
The second requirement is a bit tougher. You don't really specify how the user gets a role of "HelpDesk" (profile property? SharePoint group?). Depending on how it is setup, you may be able to use an AJAX call to the SharePoint webservices to check their security. Or you could write a custom webpart that validates their role and then emits some JavaScript.
Use Infowise Smart List Lite, the free version of our Smart List Pro product. Your requirement is just one of its many features.
I have a list with the fields: Title, Client, Project, Description.
There is a view for analysts with the fields visible: Title, Project, Description.
All is fine so far as the analysts work with their views and not with the lists. But when they need to modify the records clicking on Edit, they see and able to modify the 'Client' field too.
How to prevent 'Client' field to be available for editing by the group? is there a way in WSS or I need to look for 3rd party list components?
All fields have a set of properties that determine their visibility in forms, such as "ShowInNewForm", "ShowInEditForm", and "ShowInDisplayForm". There's also some for the file dialog, the list settings page, and a few other places, but that's getting past it. Short answer, yes, you can make the field not show up in the edit form with WSS without needing any 3rd party components.
If you need a field that cannot be seen in the Edit Form by anyone (that is, no one should be able to have it in their form), then you need to modify "ShowInEditForm" to be true. This can't be modified directly through the SharePoint UI, but it is extremely simple using the object model.
If you need certain people to edit it at some point through the SharePoint UI, then you'll instead have to create a custom edit form. That's a bit more complex, so I'll hold off on providing that instruction unless you state you need to go down that route (or someone else passes by this answer and requests it). Nevertheless, it is fully possible with WSS 3.0.
EDIT
If you know already know how to insert inline C# code into an ASPX page, you can perform this very simply using SharePoint Designer. First, follow the instructions from this article, especially make sure you don't delete the default list form web part. Now, in the custom list form you added, make it include every field which anyone will be capable of editing. The last step is to make the form hide those fields for certain people. Let's default them to Visible=false, and flip this switch if the user is allowed them. You can do this either by checking if the current user is part of specified groups, or by checking if the user has a certain permission level only held by people of those groups. You'll basically write some code like the following, I'll use checking for a specified group as the example.
using (SPWeb web = this.Web)
{
SPUser currUser = web.CurrentUser;
string[] listOfGroups = { "Group1Name", "Group2Name", "Group3Name" };
foreach (string groupName in listOfGroups)
{
if (currUser.Groups.Contains(groupName))
{
//Repeat this for each Control, refer to them by their ID. For example, this is for a control with the ID txtTitle.
txtTitle.Visible = true;
}
}
}
If you don't know inline code, you'll have to write a custom ASPX page with a code-behind. Copy EditForm.aspx into a new file - you should do this after setting up a Custom List Form as per the article. You could also build a new ASPX page from scratch, but make sure you include all of the necessary Content placeholders for SharePoint pages. Now, the page currently inherits from Microsoft.SharePoint.WebPartPages.WebPartPage. We need to create custom code that inherits from that class, and change the page to inherit that new custom code instead. In the custom code, override one of the OnLoad or OnInit methods, and include your check for the user's permissions there as detailed earlier. Compile the code, deploy it to your SharePoint server, and it should be functional.
If you want to set fields hidden or display them in new form or edit form page of the list...
Go to the list settings.
In Advanced Settings, enable "Allow management of content types"
By doing so, you will get a List name Link on the List Setting Page.
Open the link and select the fields that you want to hide or uhide using add or remove option.
After saving this, again disable "Allow management of content types" in Advanced Setting...
Thats it :)))