46
Bug reports / Re: Permission problems in latest betas
« on: January 23, 2009, 01:52:36 AM »
Ah.. so I'm not crazy. 
Thanks!
Edit: Works correctly in build 220.
Thanks!
Edit: Works correctly in build 220.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
Bug reports / Re: Permission problems in latest betas
« on: January 21, 2009, 04:43:45 AM »
(build 219)
Hi rejetto,
I finally got around to trying {.set item|/template|access=@anyone.} and nothing appears to happen. The same with @any account and @anonymous. Is that the proper syntax? Giving access to a specific account with {.set item|/template|access=testaccount.} works just fine.
Hi rejetto,
I finally got around to trying {.set item|/template|access=@anyone.} and nothing appears to happen. The same with @any account and @anonymous. Is that the proper syntax? Giving access to a specific account with {.set item|/template|access=testaccount.} works just fine.
48
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 08, 2009, 07:25:41 AM »QuoteOne problem, though. I have an account missing in both dropdowns. It just happens to be the first one in the list in my HFS.I also have the first account missing in the dropdown list.
Mars
Not sure if thisQuoteYou can correct the problem the by replacing [ ,;] by [;] in each of themwas to be the "fix" for this. If so, it didn't.
I don't think that was to fix the bug I reported. I'm pretty sure it was to fix this:
Small bug indicated by silentpliz:
The accounts containing a space or a comma appeared on two lines
I'm guessing SilentPliz reported it to mars elsewhere, because I never saw a post about it here in this thread. I did try it anyway just to see if it might help, but it didn't.
However, SilentPliz's default_Updated.tpl in the post right after mars' fix does work. Don't ask me what the difference is, though. Heh
49
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 07, 2009, 03:17:17 AM »
Looking good, guys!
I think Ryan J missed a turn or two, but I'm sure he's learning a lot!
I think Ryan J missed a turn or two, but I'm sure he's learning a lot!
50
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 06, 2009, 01:42:35 AM »
(build 218)
Nice mars!
One problem, though. I have an account missing in both dropdowns. It just happens to be the first one in the list in my HFS.
Also, I was able to change the admin username requirement to my own, but I had to restart HFS to make it take effect. It's strange that some templates seem to require it and some don't...
Edit:
Hmpf! Just for the heck of it, I just changed it back to admin and then back again to my login and it worked both times without restarting HFS. Hmmm... Beats me!
Nice mars!
One problem, though. I have an account missing in both dropdowns. It just happens to be the first one in the list in my HFS.
Also, I was able to change the admin username requirement to my own, but I had to restart HFS to make it take effect. It's strange that some templates seem to require it and some don't...
Edit:
Hmpf! Just for the heck of it, I just changed it back to admin and then back again to my login and it worked both times without restarting HFS. Hmmm... Beats me!
51
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 05, 2009, 12:41:06 AM »Add a false section here:
[special:strings]
menu=.: Menu / Options :.
[fake section]
Ah.. of course. I hadn't realized I also "broke" the menu text.
As you are not obliged to destroy the whole section.
You never know ... If a French is in need near you.
I'd probably need to live a lot farther north east. With the border that I'm close to, I'm more likely to need Spanish.
If the section is really unnecessary ... you can remove all ... except:
[special:strings]
menu=.: Menu / Options :.
The fake section works fine for me!
Thanks!
52
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 04, 2009, 11:45:05 PM »Attachment updated... Everything works fine!
Where did the English go??
Edit:
Oh... I figured it out! Don't ask me how. Heh I was looking through it and figured that if I "broke" the [special:strings] section that it might work, and it does! I stuck [blah] in after that tag, but I'm sure the whole section could just be removed, too.
Very clever! :-)
53
Bug reports / Re: Permission problems in latest betas
« on: January 04, 2009, 09:51:46 AM »
Ooooops..... 
I just realized that this actually has to do with the templates I've been playing with.
RAWR-Template
Terayon
Thunderchicken of Glory
They import their own template folders and set the flags. Color me embarrassed! (if you couldn't already tell. heh) But I am learning!
Anyway, of course it's still necessary for me to change the Access to the templates folder to allow "Anyone" for situations like this thread is about.
So after making this discovery, I checked the wiki and there doesn't appear to be a way using a macro to enable the "Anyone" permission in the Permissions/Access panel. The same goes for the "Any account" and "Anonymous" permissions. I would think these would be equally as important as the current ability to assign specific users.
I just realized that this actually has to do with the templates I've been playing with. RAWR-Template
Terayon
Thunderchicken of Glory
They import their own template folders and set the flags. Color me embarrassed!
(if you couldn't already tell. heh) But I am learning! Anyway, of course it's still necessary for me to change the Access to the templates folder to allow "Anyone" for situations like this thread is about.
So after making this discovery, I checked the wiki and there doesn't appear to be a way using a macro to enable the "Anyone" permission in the Permissions/Access panel. The same goes for the "Any account" and "Anonymous" permissions. I would think these would be equally as important as the current ability to assign specific users.
54
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 04, 2009, 03:19:40 AM »I'm sorry but if you read my first post:
http://www.rejetto.com/forum/index.php?topic=6492.0
You can see; that I am a complete n00b when it comes to programming of any kind, and the stages it took me to learn about macros.
I am still quite pleased that I managed to learn alot about macros/html and make this in only two days.
I hope I will be able to do things like this properly in the future but for now I am still learning.
No problem at all. I was just curious. I see from mars' version that it is possible to do it in one step, so now we both know.
This does indeed disable the account but the line I use is notCode: [Select]{.set account|{.^accountname.}|enabled=true.}it is:Code: [Select]{.set account|{.^accountname.}|enabled={.^accountstatus.}.}
Are you sure you are editing the:[statuschange] section and not the:[newusermake] section?
You missed the part where I said I changed the command after an account is created as a test.
It still didn't disable the account, but mars explained that the field actually needs to be blank rather than "false".The typo is my bad though.
That's ok. Since the field actually needs to be blank to disable, it needs reworded anyway.
I will hopefully make a newer version later on - probably based on Mars' one in the post above
Looking forward to it!
55
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 03, 2009, 08:07:57 PM »
(using beta build 218)
Disabling accounts doesn't work for me either. In fact, if I disable an account from inside HFS and then go through the motions of trying to disable it (again) through Admin Panel, it actually gets re-enabled.
Is this maybe a bug in HFS?
The bulk of the contents of template files is still a mystery to me, but I *think* I manged to change the command after a new account is created to set it to be disabled as a test, but it still ends up enabled. Here is what I changed:
{.set account|{.^accountname.}|enabled=true.}
to:
{.set account|{.^accountname.}|enabled=false.}
Also, I believe there is a typo in the following line. In the parenthesis after "false", shouldn't it be "without quotes" instead of "with quotes"?
Then type "true" (without quotes, to enable) or "false" (with quotes, to disable), click submit then click Change.
And finally, I'm afraid I have to ask. Why is it necessary to click two things to invoke a change? Isn't it possible to do these things in one step using variables instead of two with intermediate .txt files?
Disabling accounts doesn't work for me either. In fact, if I disable an account from inside HFS and then go through the motions of trying to disable it (again) through Admin Panel, it actually gets re-enabled.
Is this maybe a bug in HFS?The bulk of the contents of template files is still a mystery to me, but I *think* I manged to change the command after a new account is created to set it to be disabled as a test, but it still ends up enabled. Here is what I changed:
{.set account|{.^accountname.}|enabled=true.}
to:
{.set account|{.^accountname.}|enabled=false.}
Also, I believe there is a typo in the following line. In the parenthesis after "false", shouldn't it be "without quotes" instead of "with quotes"?
Then type "true" (without quotes, to enable) or "false" (with quotes, to disable), click submit then click Change.
And finally, I'm afraid I have to ask. Why is it necessary to click two things to invoke a change? Isn't it possible to do these things in one step using variables instead of two with intermediate .txt files?
56
Bug reports / Upload permission inheriting
« on: January 03, 2009, 08:27:16 AM »
Hi rejetto,
Sorry, don't mean to complain twice in one day, but I think I found another bug or two.
Using beta build 218, but I don't know when this problem started or if it's always been there because I've never tried it before.
I have Upload permission set to "Any account" for the root, which is bound to a real folder. Inside HFS, tooltips for real subfolders say "Upload allowed for: @any account [inherited]". But when going into that subfolder in a browser, the Upload option is not available as expected, unless I specifically set it for that subfolder.
Strangely, virtual subfolders and even files also say "Upload allowed for: @any account [inherited]", which doesn't make sense. You're only supposed to be able to upload to real folders, right?
And finally, if I unbind the root from the real folder where I'd previously allowed uploading, the subfolders (real and virtual) and files' tooltips still say "Upload allowed for: @any account [inherited]", even though there's no way to edit that permission with the root now being virtual. I would think that with the root being virtual, that "ghost" permission shouldn't even exist for something below to inherit.
Any questions or want me to try something? Just ask.
Sorry, don't mean to complain twice in one day, but I think I found another bug or two.
Using beta build 218, but I don't know when this problem started or if it's always been there because I've never tried it before.
I have Upload permission set to "Any account" for the root, which is bound to a real folder. Inside HFS, tooltips for real subfolders say "Upload allowed for: @any account [inherited]". But when going into that subfolder in a browser, the Upload option is not available as expected, unless I specifically set it for that subfolder.
Strangely, virtual subfolders and even files also say "Upload allowed for: @any account [inherited]", which doesn't make sense. You're only supposed to be able to upload to real folders, right?
And finally, if I unbind the root from the real folder where I'd previously allowed uploading, the subfolders (real and virtual) and files' tooltips still say "Upload allowed for: @any account [inherited]", even though there's no way to edit that permission with the root now being virtual. I would think that with the root being virtual, that "ghost" permission shouldn't even exist for something below to inherit.
Any questions or want me to try something? Just ask.
57
Bug reports / Re: Permission problems in latest betas
« on: January 03, 2009, 05:58:29 AM »
Hi rejetto,
Sorry to have to dig this bug back up!
I'm using beta build 218 now. You might want to skim through the previous messages if you need a refresher on what the problem was.
I ran into this problem again using a customized template. I was using the built-in/default template before and that continues to work. I just never tried it while using a customized template until now.
The problem appears to be in the way the template folder inherits its permissions from the root. I can "fix" it by changing the template folder's permissions to give access to "Anyone". This also allows access by an account that only has permission to folders other than the root, like the situation we worked on before. Also, doing this allows the template to be used when no anonymous access is given and someone does not successfully log in, by allowing the "Unauthorized" page to look like it's supposed to.
So, I have two questions...
1) Are there any security risks using this "fix"? I don't know why there would be, but you know a lot more about how things work than I do.
2) If this actually is the proper way to fix this, could you make it so that permission is automatically assigned to the template folder when a customized template is assigned?
Of course, if you have any questions, feel free to ask!
Sorry to have to dig this bug back up!
I'm using beta build 218 now. You might want to skim through the previous messages if you need a refresher on what the problem was.
I ran into this problem again using a customized template. I was using the built-in/default template before and that continues to work. I just never tried it while using a customized template until now.
The problem appears to be in the way the template folder inherits its permissions from the root. I can "fix" it by changing the template folder's permissions to give access to "Anyone". This also allows access by an account that only has permission to folders other than the root, like the situation we worked on before. Also, doing this allows the template to be used when no anonymous access is given and someone does not successfully log in, by allowing the "Unauthorized" page to look like it's supposed to.
So, I have two questions...
1) Are there any security risks using this "fix"? I don't know why there would be, but you know a lot more about how things work than I do.
2) If this actually is the proper way to fix this, could you make it so that permission is automatically assigned to the template folder when a customized template is assigned?
Of course, if you have any questions, feel free to ask!
58
HTML & templates / Re: Admin Panel : Creating a proper admin panel.
« on: January 03, 2009, 12:50:23 AM »
Hi Ryan,
Sounds really cool, but I get a 0 byte Zip file when I try to download it.
I tried your modded TCOG template, but I don't know how to get to the admin panel without the docs in the Zip file.
Edit: Aha! I figured out how to get to the ~adminpanel.
Sounds really cool, but I get a 0 byte Zip file when I try to download it.
I tried your modded TCOG template, but I don't know how to get to the admin panel without the docs in the Zip file.
Edit: Aha! I figured out how to get to the ~adminpanel.
59
Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 25, 2008, 07:58:18 PM »
Hi rejetto,
No-IP changed something and now it's working again. They are returning just a single line now for the URL in my first post, for example:
mydomain:1
No-IP changed something and now it's working again. They are returning just a single line now for the URL in my first post, for example:
mydomain:1
60
Bug reports / Re: No-IP update error in 2.3 beta Build 203
« on: September 19, 2008, 05:47:09 PM »
Ok, thanks rejetto!