I set the Password Expiry Reminder to 14 or XX days and clicked update. Then I looked at it again it showed default values 7 days.
It never update the Password Expiry Reminder (in days) field, Is there bug in DNN.
I tried changing it to a number of days less than 7 and it doesn't set that either.
Could you please let me know what should I do? Please
Thanks and regards
Mohsin JK
I just tested this in DotNetNuke 5.6.1. In fact, the setting is updated in the database (check it with:
SELECT [SettingName]
,[SettingValue]
,[SettingIsSecure]
,[CreatedByUserID]
,[CreatedOnDate]
,[LastModifiedByUserID]
,[LastModifiedOnDate]
FROM [DNN56].[dbo].[DNN_HostSettings]
where
[SettingName] = 'PasswordExpiryReminder'
) but in fact the web user interface always displays '7', despite the value stored in database.
Edited:
I did some further tests and came to realize that reading the value of the property PasswordExpiryReminder of PasswordConfig always returns 7!
int i = DotNetNuke.Security.Membership.PasswordConfig.PasswordExpiryReminder;
So I turned it into
int i = DotNetNuke.Entities.Controllers.HostController.Instance.GetInteger("PasswordExpiryReminder");
and this time it returned -1 (because I'm not using the overload supplying a default value).
Then I had a flash, turned to SSMS and copied the value of the column SettingName and pasted it in Visual Studio.
int i = DotNetNuke.Entities.Controllers.HostController.Instance.GetInteger("PasswordExpiryReminder ");
Notice the trailing space? And with this code the real number stored in the table is returned. Look someone has a bug.
This appears to be a bug in DotNetNuke, I've reproduced it myself on my own website.
I've added this to Gemini as an issue http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=19436&PROJID=2
I'm looking to see if I can come up with a work around as well.
Related
I'm attempting to provide support for a legacy ASP/MSSQL web application - I wasn't involved in the development of the software (the company that built it no longer exists) & I'm not the admin of the server where it's hosted, I just manage the hosting for the owners of the site via a reseller account. I'm also not an ASP developer (more a PHP guy), and am not that familiar with it beyond the basics - updating DB connection strings after server migrations, etc.
The issue is that the site in question stores the content of individuals pages in an MSSQL database, and much of the content includes links. Almost all of the internal links on the site are format like "main.asp?123" (with "123" being the ID of a database row). The problem is, starting sometime in the last 8 months or so*, something caused the links in the DB content to show up as "main.aspÀ123" instead - in other words, the "?" character is being replaced by the "À" character (capital A with grave accent). Which, of course, breaks all of those links. Note that Stackoverflow won't allow me to include that character in the post title, because it seems to think that it indicates I'm posting in Spanish...?
(*unfortunately I don't know the timing beyond that, the site owners didn't know when the issue started occurring, so all I have to go by is an archive.org snapshot from last October, where it was working)
I attempted to manually change the "?" character in one of the relevant DB records to "?" (the HTML entity for the question mark), but that didn't make any difference. I also checked the character encoding of the HTML code used to display the content, but that doesn't seem to be the cause either - the same ASP files contain hard-coded links to some of the same pages (formatted exactly the same way), and those work correctly: the "?" doesn't get replaced.
I've also connected to the database directly with the MSSQL Management Studio Express application, but couldn't find any charset/character encoding options for either the database or the table.
And I've tried contacting the hosting provider, but they (M247 UK, in case anyone is curious) have been laughably unhelpful. The responses from them have been along the lines of "durrrrrr, we checked a totally different link that wasn't actually the one that you clearly described AND highlighted in a screenshot, and it works when we check the wrong link, so the problem must be resolved, right?" Suffice it to say, I wouldn't recommend them - used to be a customer of RedFox hosting, and the quality of customer has dropped off substantially since M247 bought them.
Any suggestions? If this were PHP/MySQL, I'd probably start by creating a small test script that did nothing but fetch one of the relevant records and display it's contents, to narrow down the issue - but I'm not familiar enough with ASP to do that here, at least not without a fair amount of googl'ing (and most of the info I can find is specific to ASP.net instead).
Edit: the thread suggested as a solution appears to be for character encoding issues when writing to MSSQL, not reading from it - and I've tried the solutions suggested in that thread, none make any difference.
Looks like you're converting from UNICODE to ASCII somewhere along the line...
Have a look at this to get a quick demo of what happens. In particular, pay attention to the ascii derived from inr, versus the ascii derived from unicode...
SELECT
t.n,
ascii_char = CHAR(t.n),
unicode_char = NCHAR(t.n),
unicode_to_ascii = CONVERT(varchar(10), NCHAR(t.n))
FROM (
SELECT TOP (1024)
n = ROW_NUMBER() OVER (ORDER BY ao.object_id)
FROM
sys.all_objects ao
) t
WHERE 1 = 1
--AND CONVERT(varchar(10), NCHAR(t.n)) ='À'
;
I found a workaround that appears to do the trick: I was previously trying to replace the ? in the code with ? (took out the ; so that it will show the code rather than the output), which didn't work. BUT it seems to work if I use &quest instead.
One thing to note, it seemed that I was originally incorrect in thinking that the issue was only affecting content being read/displayed from the MSSQL DB. Rather, it looks like the same problem was also occurring with static content being "echo'd" by code in the ASP scripts (I'm more of a PHP guy, not sure the correct term is for ASP's equivalent to echo is). Though the links that were hardcoded as static (rather HTML being dynamically output by ASP) were unaffected. Though chancing the ? to &quest worked for those ones too (hardest part was tracking down the file I needed to edit).
OK, so, here's an odd one, which is causing me to lose what little hair I have left.
We have some code that uses ADO to pull data from SQL Server. The code's been in place for 7 or 8 years now, and hasn't been touched for quite a while.
In the function, where we check the returned field's type for some conversion, we have this:
case ( fieldType = ADDBTIMESTAMP$ )
* // A date/time stamp (yyyymmddhhmmss plus a fraction
* // in billionths)
* // Looksd like we're just getting MM/DD/YYYY
* // ooh no sometimes we get 6/25/2010 11:35:00 AM
Basically, this is saying that when the field's type is ADDBTIMESTAMP (or 135), then for whatever reason, the date is being returned MM/DD/YYYY sometimes with, and sometimes without a time stamp.
This morning, all date fields are now returning values YYYY-MM-DD (dashes included).
I haven't changed this code. The network people swear up and down that they haven't updated or modified SQL Server. My workstation is Win10, so who knows what's changed on that, but I don't see any indication of updates for the past few days.
Obviously, something's changed, considering we're now getting the data back in a what should be the correct format, but for the life of me, I can't see what could have happened.
Any help or tips or psychiatric recommendations would be appreciated.
Thanks.
Basically, it's a configuration issue on the workstation I'm using. No other workstation appears to have the problem. I don't think I'll ever find out what happened. To be honest, now that I've looked at the code, which I've never needed to before, I'm more concerned that it's always been returning wrong on every machine for the last 7 or 8 years.
It's things like this that make me want to go into a less stressful line of work, like opening a restaurant.
Thanks.
I have a report with a multi-valued parameter on it. I'm looking to output the selected values which is accomplished with Join(Parameters!State.Label,",")
Every solution I've found on the web indicates I should use something like the following to detect when the (Select All) "value" is selected.
E.g. expression for the text box on the header should be:
="State: " & IIF(countrows("prc_prompt_state").Equals(Parameters!State.Count),"(All)",join(Parameters!State.Label,","))
CountRows() tells me the total number of parameters available, e.g. 8 states in Australia. Parameters!State.Count is supposed to tell me how many are actually selected by the user. However this always reports the full value (8 in this case) regardless of how many are selected. This is in agreement with the official docs (https://technet.microsoft.com/en-us/library/aa337293(v=sql.100).aspx), but NOT in agreement with every single search result I come up with on how to solve this problem.
So how can I rewrite this expression so I can find out when (Select All) is/isn't checked? I'm using report builder 3, which I believe is based on the 2008 edition - we deploy to Azure, but I haven't got that far yet.
Examples of questions whose answers seem to be wrong:
Displaying Multi-Value Parameters
SSRS: Can I know if user selected "ALL" in multivalued param?
This is old, but google found it for me, and then I figured out an answer on my own that worked. (I was using a list of users.)
I created a separate dataset that returns a count of all available options in the default parameter lookup (username). Then, I assigned that as a default value to an internal parameter. (UserCount) This worked as a text expression:
=Microsoft.VisualBasic.Interaction.IIF(Parameters!username.Count = Parameters!UserCount.Value, "All Selected", Microsoft.VisualBasic.Strings.JOIN(Parameters!username.Value, ", "))
I need to generate a year drop down with cake to populate ArchiveQuarter.year in the database. This is currently set in the database to 'year', but it was producing the same results with 'date'.
This is the current setup:
echo $this->Form->input('ArchiveQuarter.year', array(
'label'=>'Year',
'type'=>'date',
'dateFormat'=>'Y',
'minYear'=>'2000',
'maxYear'=>date('Y'),
));
The problem is that this produces a dropdown with a range of 1970-2013 instead of 2000-2013. The minYear does work though, because if you set it below 1970 then it will indeed work.
I literally copied and pasted your code into my CakePHP 2.3.0 app, and it worked as expected - gave me a select input from 2013 to 2000.
Maybe try getting the most recent version of CakePHP (your question doesn't list what version you're using) and try that?
Bottom line, the code you've provided does work - so if it's not for you, there are other factors in play.
I did some research into what was going on within the FormHelper.php file and here is a breakdown:
In the dateTime() function it checks if $attributes['value'] is empty. If it is it fills that information using $this->value($attributes,$fieldName); populating it with 2013
2013 is then parsed by _GetDateTimeValue()
Within _GetDateTimeValue() it is parsed as numeric, and is translated from unix time; an hour and a half into 1970.
That then is set as the value of the final select box, which has to expand from the minYear to properly accommodate.
For whatever reason Cake does not take into account the explicitely stated dateFormat=>'Y' when is parses with _GetDateTimeValue().
The solution is to insert: $selected => strtotime('now') which will in the end get properly parsed.
You can also explicitly set $selected to values outside of the range of dates, which I'm not sure would be a wanted before or not.
I'm working on a report in Reporting Services and I can't figure out why I'm having trouble with Non-queried report parameters.
I'm trying to get the current year and have tried:
=YEAR(TODAY())
=DATEPART("yyyy",TODAY())
I have also tried TODAY instead of TODAY()
All of these seem to break the Year dropdown on my report. I thought if something was wrong it would just not get the correct default... but nope, it breaks the whole field.
Any thoughts? articles?
UPDATE:
Wait, wait, wait... the weirdest thing. The Year parameter is the second parameter of this report. And its grayed out (with no value) UNTIL I select the first parameter (im my case "category"). Am I somehow telling the Year param to do this? or does SSRS 2005 process the params in order? I don't think I ever noticed this before.
UPDATE 2:
Please see all comments
=DateTime.Today.Year
should work as well.
Edit: Bruno - i have the same behavior as you are seeing. I created a sample report with a string first parameter with no default value, and a string 2nd parameter with a default of =DateTime.Today.Year. When I have the one with the default as the 2nd parameter in the order, it shows up empty and disabled.
I was able to fix this problem 2 ways: first by adding a default of =String.Empty to my first parameter, and the second way was to just change the order of the parameters.
Not sure if this behavior is by design or a bug - but like you said, I hadn't noticed it either until today when you pointed it out in your question.
Try:
=Year(Now)
I'm not sure if this is what you need, but it worked for me. I used it to form a date string so I used =Year(Now).ToString().
SSRS does process the report parameters in order - order can be important if you have dependencies between your parameters.
From MSDN: "Parameter order is
important when you have cascading
parameters, or when you want to show
users the default value for one
parameter before they choose values
for other parameters."
So, it will always wait until you have a default value for your first parameter or you enter the first parameter's value, before it processes the next one, and so on.
http://msdn.microsoft.com/en-us/library/cc281392.aspx
I found the by making sure that ALL of my parameters had at least some default value, then you will not experience they greyed out datetime picker. So, every parameter before your datetime paremeter in order needs to have a (default) value or it will not work.
Def due to order of evaluation of parameters.
Simple workaround ; in the parameters tab you can change the order of the parameters - this will move the date pickers to the top of the list and are then enabled straight away, on my server at least.
Someone raised the issue of basing a date filter on a queried default value - if you do this, you will notice a very annoying knock-on effect of getting screen refresh any time the dates get changed, before you have a chance to requery the reports.